2016-08-12 セキュリティ・キャンプ全国大会2016 #seccamp インフラセキュリティブートキャンプ

1. インフラセキュリティ
ブートキャンプ
株式会社WHERE
IoT基盤センター サービスプロデューサー
兼 情報システム室 インフラエンジニア
仲山 昌宏 ( @nekoruri )

2. 講師プロフィール
• 仲山昌宏
• いわゆるインフラエンジニア＋ウェブアプリ開発者
• 秋葉原生まれ大手町育ちの
歌って踊れる江戸っ子インフラエンジニア
• 株式会社WHERE
IoT基盤センター サービスプロデューサー
兼 情報システム室 インフラエンジニア
2

3. 経歴
• 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
↓

4. 主なスキルセット
• システム設計
• クラウドとIoTデバイス組み合わせて
良い感じのシステム
• ウェブアプリの内部アーキテクチャ
• アプリケーション開発
• メインはサーバサイド
Perl、Ruby、Python、JS、PHP
• 過去にはWindowsとかも
• 最近IoTデバイスの内蔵マイコンにも
手を出し始めた
• 情報システム
• 社内ITシステムの設計、運用
• 情報セキュリティマネジメント
• サーバ/ネットワーク運用
• サーバHW（特にストレージ）周り
• IPネットワーク
• 「必要があればなんでもやる」
4

5. この講義の目的
• セキュアなWebサービスインフラの構築・運用技術
• クラウド時代のサービス運用のポイント
• コードで管理されたサーバインフラの運用
• アプリケーションコンテナの活用
• サーバレスアーキテクチャ
• 負荷試験
5

6. 進め方
• 基礎知識・ポイントの解説
• グループワーク
• 3人1グループでシステムを一つ作ってもらいます
• seccamp Slackでプライベートグループを作り、
作業内容を逐次そこに報告してください
• 最後に個人ごとに各自3分くらいの発表
6

7. サービスの運用とは
• 目的：
• ITを使って「お金を稼ぐ」
• 手段：
• お客さんにサービスを提供し、その対価を受け取る
（直接部門）
• 従業員にサービスを提供し、生産性を向上させる
（間接部門）
7

8. サービスの価値
• 使いたいときに使える（落ちない）こと
• いわゆる「サービスの品質」
• そもそも：
• サービスの内容がお客さんの期待を満たすこと
8

9. サービスの価値
• 使いたいときに使える（落ちない）こと
• いわゆる「サービスの品質」
• そもそも：
• サービスの内容がお客さんの期待を満たすこと
し続けること
9

10. サービスインフラの使命
• サービスの価値を利用者に届け続ける
• 新しい機能をすぐに届ける
• 既存の機能も安定して届け続ける
• クラウドの活用で実現
10

11. DevOps
• 過去：
• 新しい機能をすぐに届ける → 開発者(Dev)の仕事
• 既存の機能も安定して届け続ける → 運用者(Ops)の仕事
• 新しい機能に不具合が多いとシステムは安定しない
⇒ DevとOpsで利害の対立、意思決定の分離
• DevOps：
• クラウドの活用で、意思決定を一つに
11

12. クラウドのサービス分類
• いわゆるIaaS
• サーバ単位で借りる
• いわゆるPaaS
• 機能単位で借りる
• Heroku、AWS Lambdaのような実行環境
• Amazon RDSやAWS IoTのような具体的な機能
12

13. IaaSの利用
• サーバを自前で用意せずクラウドで借りる
• 大きな変化は無いが、
スケールアップ（性能を上げる）
スケールアウト（台数を増やす）
のようなメリットは得られる
13

14. PaaSの活用
• 「ありもの」を組み合わせる
• 餅は餅屋モデル
• 「EC2使ったら負け」
• アプリケーション開発自体の変化が強いられる
• 上手くはまる＝最適化できると画期的なコスト減も
14

15. Amazon Web Services
• 世界で一番大規模なクラウド事業者
• 対抗馬はMicrosoft Azure
• シェアはまだ大きな差がある
• 機能面では追いつきつつある（部分的に先行）
15

16. AWSの特徴
• 責任共有モデル
• OSから上を利用者が責任を持つ
（アマゾンは責任を持たない）
• OSから下はアマゾンが責任を持つ
• 独特な冗長化設計
• リージョンとアベイラビリティゾーン
16

17. リージョンとアベイラビリティゾーン
• リージョン（Region）
• 一つの地域に置かれ、システム的に独立したまとまり
• 「東京」「オレゴン」「北カリフォルニア」
• アベイラビリティゾーン（AZ）
• 1つのリージョン内に複数設置されたまとまり
• 一つの故障が複数のAZで併発しないように分離
• 個別のデータセンターを想定
17

18. AWSでの冗長化の基礎
同じ役割のサーバを、各AZで半々に設置
18
ap-northeast-1a ap-northeast-1c
Web Web
DBDB
ap-northeast-1

19. AWSでの冗長化の基礎
• 「サーバ」という枠がないもの
• Elastic Load Balancer （ロードバランサー）
• DynamoDB （NoSQLデータベース）
• などなど
• これらはAZを意識せずに冗長化されている
• これらの活用が運用を楽にする勝利の鍵
19

20. Amazon VPC
• AWS内に「自分のネットワーク」を確保する枠組み
• あえて作らなくても「デフォルト」のVPCが存在する
• VPCのIPアドレスブロック 例：10.0.0.0/16
• AZごとのサブネット 例：10.0.1.0/24
• AZごとのサブネット 例：10.0.2.0/24
20

21. サーバインフラのコード化
• 「Infrastructure as Code」
• サーバ構成をコード（具体的にはJSONやRubyベースの
DSLなど）で実装し、それをもとにAPIをたたいて展開
21

22. HashiCorp
• クラウドを管理するツールの開発会社
• OSSでツールを提供
• Vagrant、Packer、Terraform、Serf、Consul、Vault……
22

23. Terraform
• AWSやAzureの構成をコード化
• コードに合わせて必要なサーバやコンポーネントを作成
• 不必要になったら削除
• JSONで書く
• 今回はTerraformでAWSを操作してもらいます
23

24. Terraformの使い方
• 公式ドキュメントのIntroduction参照
• https://www.terraform.io/intro/getting-started/install.html
• DESTROY INFRASTRUCTUREまででOK
24

25. 演習の準備
• Slackの準備
• seccamp Slackに登録
• ユーザ名を教えてください
• private channneに招待します
• GitHubの準備
• GitHubのユーザが無い人は登録
• ユーザ名を教えてください
• プライベートレポジトリに招待します。
• 別にプライベートレポジトリが必要になったら声を掛けてください。
25

26. 演習 #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

27. 前半おさらい
• Terraform
• ネットワーク構成などの自動化
• Docker
• アプリケーションを丸ごとパッケージ
• DockerHubで共有できる
27

28. 後半

29. 後半のゴール
• Dockerでアプリを立ち上げてみる
• サーバレスアーキテクチャに触れてみる

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

31. アプリケーションコンテナ
• アプリケーションの実行環境をパッケージにしたもの
• ファイルシステム一式
• OS環境
• 必要なライブラリ・ミドルウェア
• アプリケーション本体
• コンテナ起動時に実行するコマンドライン
• 外部に公開する(LISTENする)TCPポート番号
• 外部と共有するファイルシステムのパス
31

32. Docker
• アプリケーションコンテナの実行環境＋α
• DockerHubから取ってきて立ち上げる
• 複数のコンテナを同時に管理する docker-compose
• その他様々な管理ツールの集合体
32

33. 演習 #02
• 先ほどのAmazonLinux上に、Dockerをインストール
• Dockerでオープンソースのアプリを動かしてみる
• http://qiita.com/y_hokkey/items/406b5a8c4bc15354d069
• このあたりから適当に選んでください。
参考までに「Reichat」の作者はセキュキャン勢です。
• ELB経由で見えるようにする
• （もう1台はいったんLBから抜いてください）
33

34. サーバレスアーキテクチャ
• 最近流行りのキーワード
34

35. 二つのサーバレスアーキテクチャ
• アプリケーション実行環境としてのサーバレス
• アプリケーションサーバという役割としてのサーバレス

36. サーバレスなアプリケーション実行環境
• 「フルマネージドなPaaS」の発展系
• 短時間で起動する
• 実際の実行時間で課金される
• 利用者にとって「サーバ」という管理単位がなくなる

37. 「アプリケーションサーバ」レス
• モノリシックな「アプリケーションサーバ」
• デーモンとして常に起動してポートをLISTEN
• リクエストをハンドリング
• バッチ処理なども
• 細かい「マイクロサービス」の集合に分割
• 一つの大きな「アプリケーションサーバ」が消失

38. リアクティブアーキテクチャ
リアクティブ宣言：近代的なシステムを実現するための設計原則
1. 即応性（実現したい価値）
• システム全体として素早く、かつ安定した応答時間を保つ。
2. 耐障害性（非機能要件）
• 障害が発生しても、それをコンポーネント内部に影響を隔離することで、システム全体としての即応性を保つ。
3. 弾力性（非機能要件）
• 負荷の増減があっても、ボトルネックを排除し、割り当てるリソースを調整することで、即応性を保つ。
4. メッセージ駆動（アーキテクチャ構成要件）
• 各コンポーネント間を、非同期なメッセージ配信で疎結合に保つ。

39. リアクティブアーキテクチャ
• 超ざっくり言うと、
• 小さなプログラムを
• メッセージ駆動で
• 繋いでいく
• というアーキテクチャが良い、というものです。
39

40. 演習
• AWS LambdaのBlueprintから一つ動かしてみる
• hello-world系を除く
• おすすめはslack-echo-command
40

41. 発表
• 9人それぞれ、
• どこまでできたか
• どこで苦労したか
• どんな発見があったか
• それぞれ3分くらいで発表してください。

42. 後半おさらい
• サーバレスアーキテクチャ
• リアクティブシステム
• AWS Lambda
• Docker
• アプリケーションを丸ごとパッケージ
• DockerHubで共有できる
42