インフラセキュリティブートキャンプ

株式会社WHERE

IoT基盤センターサービスプロデューサー兼 情報システム室インフラエンジニア

仲山昌宏 ( @nekoruri )

講師プロフィール

•仲山昌宏

•いわゆるインフラエンジニア＋ウェブアプリ開発者

•秋葉原生まれ大手町育ちの歌って踊れる江戸っ子インフラエンジニア

•株式会社WHERE

IoT基盤センターサービスプロデューサー兼 情報システム室インフラエンジニア

2

経歴

• 2003-09～2005-03 大学院ネットワーク管理

• 2004-03～2010-06 WIDE Project irc.fujisawa.wide.ad.jp運用

• 2004-09～2005-10 国際大学GLOCOM (研究アシスタント)

• 2005-08～2008-09 AIP

• 2008-10～2009-12 KBB, I&D

• 2010-01～2013-06 Xtone

• 2013-07～2016-01 CyberAgent (パシャオク⇒Ameba⇒DC運用)

• 2016-02～現職 WHERE (測位技術スタートアップ) ⬅今ここ

学生

社会人

1999-04

↓

2006-03

2006-03

↓

主なスキルセット

• システム設計

• クラウドとIoTデバイス組み合わせて良い感じのシステム

• ウェブアプリの内部アーキテクチャ

• アプリケーション開発

• メインはサーバサイドPerl、Ruby、Python、JS、PHP

• 過去にはWindowsとかも

• 最近IoTデバイスの内蔵マイコンにも手を出し始めた

• 情報システム

• 社内ITシステムの設計、運用

• 情報セキュリティマネジメント

• サーバ/ネットワーク運用

• サーバHW（特にストレージ）周り

• IPネットワーク

• 「必要があればなんでもやる」

4

この講義の目的

•セキュアなWebサービスインフラの構築・運用技術

•クラウド時代のサービス運用のポイント

•コードで管理されたサーバインフラの運用

•アプリケーションコンテナの活用

•サーバレスアーキテクチャ

•負荷試験

5

進め方

•基礎知識・ポイントの解説

•グループワーク

• 3人1グループでシステムを一つ作ってもらいます

• seccamp Slackでプライベートグループを作り、作業内容を逐次そこに報告してください

•最後に個人ごとに各自3分くらいの発表

6

サービスの運用とは

•目的：

• ITを使って「お金を稼ぐ」

•手段：

•お客さんにサービスを提供し、その対価を受け取る（直接部門）

•従業員にサービスを提供し、生産性を向上させる（間接部門）

7

サービスの価値

•使いたいときに使える（落ちない）こと

•いわゆる「サービスの品質」

•そもそも：

•サービスの内容がお客さんの期待を満たすこと

8

サービスの価値

•使いたいときに使える（落ちない）こと

•いわゆる「サービスの品質」

•そもそも：

•サービスの内容がお客さんの期待を満たすことし続けること

9

サービスインフラの使命

•サービスの価値を利用者に届け続ける

•新しい機能をすぐに届ける

•既存の機能も安定して届け続ける

•クラウドの活用で実現

10

DevOps

•過去：

•新しい機能をすぐに届ける → 開発者(Dev)の仕事

•既存の機能も安定して届け続ける → 運用者(Ops)の仕事

•新しい機能に不具合が多いとシステムは安定しない⇒ DevとOpsで利害の対立、意思決定の分離

• DevOps：

•クラウドの活用で、意思決定を一つに

11

クラウドのサービス分類

•いわゆるIaaS

•サーバ単位で借りる

•いわゆるPaaS

•機能単位で借りる

• Heroku、AWS Lambdaのような実行環境

• Amazon RDSやAWS IoTのような具体的な機能

12

IaaSの利用

•サーバを自前で用意せずクラウドで借りる

•大きな変化は無いが、スケールアップ（性能を上げる）スケールアウト（台数を増やす）

のようなメリットは得られる

13

PaaSの活用

•「ありもの」を組み合わせる

•餅は餅屋モデル

•「EC2使ったら負け」

•アプリケーション開発自体の変化が強いられる

•上手くはまる＝最適化できると画期的なコスト減も

14

Amazon Web Services

•世界で一番大規模なクラウド事業者

•対抗馬はMicrosoft Azure

•シェアはまだ大きな差がある

•機能面では追いつきつつある（部分的に先行）

15

AWSの特徴

•責任共有モデル

• OSから上を利用者が責任を持つ（アマゾンは責任を持たない）

• OSから下はアマゾンが責任を持つ

•独特な冗長化設計

•リージョンとアベイラビリティゾーン

16

リージョンとアベイラビリティゾーン

•リージョン（Region）

•一つの地域に置かれ、システム的に独立したまとまり

•「東京」「オレゴン」「北カリフォルニア」

•アベイラビリティゾーン（AZ）

• 1つのリージョン内に複数設置されたまとまり

•一つの故障が複数のAZで併発しないように分離

•個別のデータセンターを想定

17

AWSでの冗長化の基礎

同じ役割のサーバを、各AZで半々に設置

18

ap-northeast-1a ap-northeast-1c

Web Web

DBDB

ap-northeast-1

AWSでの冗長化の基礎

•「サーバ」という枠がないもの

• Elastic Load Balancer （ロードバランサー）

• DynamoDB （NoSQLデータベース）

•などなど

•これらはAZを意識せずに冗長化されている

•これらの活用が運用を楽にする勝利の鍵

19

Amazon VPC

• AWS内に「自分のネットワーク」を確保する枠組み

•あえて作らなくても「デフォルト」のVPCが存在する

• VPCのIPアドレスブロック 例：10.0.0.0/16

• AZごとのサブネット 例：10.0.1.0/24

• AZごとのサブネット 例：10.0.2.0/24

20

サーバインフラのコード化

•「Infrastructure as Code」

•サーバ構成をコード（具体的にはJSONやRubyベースのDSLなど）で実装し、それをもとにAPIをたたいて展開

21

HashiCorp

•クラウドを管理するツールの開発会社

• OSSでツールを提供

• Vagrant、Packer、Terraform、Serf、Consul、Vault……

22

Terraform

• AWSやAzureの構成をコード化

•コードに合わせて必要なサーバやコンポーネントを作成

• 不必要になったら削除

• JSONで書く

•今回はTerraformでAWSを操作してもらいます

23

Terraformの使い方

•公式ドキュメントのIntroduction参照

• https://www.terraform.io/intro/getting-started/install.html

• DESTROY INFRASTRUCTUREまででOK

24

演習の準備

• Slackの準備

• seccamp Slackに登録

• ユーザ名を教えてください

• private channneに招待します

• GitHubの準備

• GitHubのユーザが無い人は登録

• ユーザ名を教えてください

• プライベートレポジトリに招待します。

• 別にプライベートレポジトリが必要になったら声を掛けてください。

25

演習 #01

• Terraformで、以下をやってみる

• VPCを作成

• VPC内部にサブネットを二つ作成

• Internet Gateway、Route table、Route table associationを追加

• セキュリティグループを設定（外部から22,80を公開、外向きに全ポートを開放）

• 各サブネットにAmazon Linuxでサーバを1台ずつ作成

• ひとまず個別にログインしてApacheインストール

• ELBを作成して、アクセスを振り分け

• 一手順ごとにGitHubにcommit

• AWSのアクセスキー自体をcommitしないように！

• Branchを切ってPullReqしたものを別の人がレビューしてマージする

26

前半おさらい

• Terraform

•ネットワーク構成などの自動化

• Docker

•アプリケーションを丸ごとパッケージ

• DockerHubで共有できる

27

後半

後半のゴール

• Dockerでアプリを立ち上げてみる

•サーバレスアーキテクチャに触れてみる

Docker

•アプリケーションコンテナの実行環境＋α

30

アプリケーションコンテナ

•アプリケーションの実行環境をパッケージにしたもの

•ファイルシステム一式

• OS環境

• 必要なライブラリ・ミドルウェア

• アプリケーション本体

•コンテナ起動時に実行するコマンドライン

•外部に公開する(LISTENする)TCPポート番号

•外部と共有するファイルシステムのパス

31

Docker

•アプリケーションコンテナの実行環境＋α

• DockerHubから取ってきて立ち上げる

•複数のコンテナを同時に管理する docker-compose

•その他様々な管理ツールの集合体

32

演習 #02

•先ほどのAmazonLinux上に、Dockerをインストール

• Dockerでオープンソースのアプリを動かしてみる

• http://qiita.com/y_hokkey/items/406b5a8c4bc15354d069

•このあたりから適当に選んでください。参考までに「Reichat」の作者はセキュキャン勢です。

• ELB経由で見えるようにする

•（もう1台はいったんLBから抜いてください）

33

サーバレスアーキテクチャ

•最近流行りのキーワード

34

二つのサーバレスアーキテクチャ

•アプリケーション実行環境としてのサーバレス

•アプリケーションサーバという役割としてのサーバレス

サーバレスなアプリケーション実行環境

•「フルマネージドなPaaS」の発展系

•短時間で起動する

•実際の実行時間で課金される

•利用者にとって「サーバ」という管理単位がなくなる

「アプリケーションサーバ」レス

•モノリシックな「アプリケーションサーバ」

•デーモンとして常に起動してポートをLISTEN

•リクエストをハンドリング

•バッチ処理なども

•細かい「マイクロサービス」の集合に分割

•一つの大きな「アプリケーションサーバ」が消失

リアクティブアーキテクチャ

リアクティブ宣言：近代的なシステムを実現するための設計原則

1. 即応性（実現したい価値）

• システム全体として素早く、かつ安定した応答時間を保つ。

2. 耐障害性（非機能要件）

• 障害が発生しても、それをコンポーネント内部に影響を隔離することで、システム全体としての即応性を保つ。

3. 弾力性（非機能要件）

• 負荷の増減があっても、ボトルネックを排除し、割り当てるリソースを調整することで、即応性を保つ。

4. メッセージ駆動（アーキテクチャ構成要件）

• 各コンポーネント間を、非同期なメッセージ配信で疎結合に保つ。

リアクティブアーキテクチャ

•超ざっくり言うと、

•小さなプログラムを

•メッセージ駆動で

•繋いでいく

•というアーキテクチャが良い、というものです。

39

演習

• AWS LambdaのBlueprintから一つ動かしてみる

• hello-world系を除く

•おすすめはslack-echo-command

40

発表

• 9人それぞれ、

•どこまでできたか

•どこで苦労したか

•どんな発見があったか

•それぞれ3分くらいで発表してください。

後半おさらい

•サーバレスアーキテクチャ

•リアクティブシステム

• AWS Lambda

• Docker

•アプリケーションを丸ごとパッケージ

• DockerHubで共有できる

42