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

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

1. 1. インフラセキュリティ ブートキャンプ 株式会社WHERE IoT基盤センター サービスプロデューサー 兼 情報システム室 インフラエンジニア 仲山 昌宏 ( @nekoruri )
2. 2. 講師プロフィール • 仲山昌宏 • いわゆるインフラエンジニア＋ウェブアプリ開発者 • 秋葉原生まれ大手町育ちの 歌って踊れる江戸っ子インフラエンジニア • 株式会社WHERE IoT基盤センター サービスプロデューサー 兼 情報システム室 インフラエンジニア 2
3. 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. 4. 主なスキルセット • システム設計 • クラウドとIoTデバイス組み合わせて 良い感じのシステム • ウェブアプリの内部アーキテクチャ • アプリケーション開発 • メインはサーバサイド Perl、Ruby、Python、JS、PHP • 過去にはWindowsとかも • 最近IoTデバイスの内蔵マイコンにも 手を出し始めた • 情報システム • 社内ITシステムの設計、運用 • 情報セキュリティマネジメント • サーバ/ネットワーク運用 • サーバHW（特にストレージ）周り • IPネットワーク • 「必要があればなんでもやる」 4
5. 5. この講義の目的 • セキュアなWebサービスインフラの構築・運用技術 • クラウド時代のサービス運用のポイント • コードで管理されたサーバインフラの運用 • アプリケーションコンテナの活用 • サーバレスアーキテクチャ • 負荷試験 5
6. 6. 進め方 • 基礎知識・ポイントの解説 • グループワーク • 3人1グループでシステムを一つ作ってもらいます • seccamp Slackでプライベートグループを作り、 作業内容を逐次そこに報告してください • 最後に個人ごとに各自3分くらいの発表 6
7. 7. サービスの運用とは • 目的： • ITを使って「お金を稼ぐ」 • 手段： • お客さんにサービスを提供し、その対価を受け取る （直接部門） • 従業員にサービスを提供し、生産性を向上させる （間接部門） 7
8. 8. サービスの価値 • 使いたいときに使える（落ちない）こと • いわゆる「サービスの品質」 • そもそも： • サービスの内容がお客さんの期待を満たすこと 8
9. 9. サービスの価値 • 使いたいときに使える（落ちない）こと • いわゆる「サービスの品質」 • そもそも： • サービスの内容がお客さんの期待を満たすこと し続けること 9
10. 10. サービスインフラの使命 • サービスの価値を利用者に届け続ける • 新しい機能をすぐに届ける • 既存の機能も安定して届け続ける • クラウドの活用で実現 10
11. 11. DevOps • 過去： • 新しい機能をすぐに届ける → 開発者(Dev)の仕事 • 既存の機能も安定して届け続ける → 運用者(Ops)の仕事 • 新しい機能に不具合が多いとシステムは安定しない ⇒ DevとOpsで利害の対立、意思決定の分離 • DevOps： • クラウドの活用で、意思決定を一つに 11
12. 12. クラウドのサービス分類 • いわゆるIaaS • サーバ単位で借りる • いわゆるPaaS • 機能単位で借りる • Heroku、AWS Lambdaのような実行環境 • Amazon RDSやAWS IoTのような具体的な機能 12
13. 13. IaaSの利用 • サーバを自前で用意せずクラウドで借りる • 大きな変化は無いが、 スケールアップ（性能を上げる） スケールアウト（台数を増やす） のようなメリットは得られる 13
14. 14. PaaSの活用 • 「ありもの」を組み合わせる • 餅は餅屋モデル • 「EC2使ったら負け」 • アプリケーション開発自体の変化が強いられる • 上手くはまる＝最適化できると画期的なコスト減も 14
15. 15. Amazon Web Services • 世界で一番大規模なクラウド事業者 • 対抗馬はMicrosoft Azure • シェアはまだ大きな差がある • 機能面では追いつきつつある（部分的に先行） 15
16. 16. AWSの特徴 • 責任共有モデル • OSから上を利用者が責任を持つ （アマゾンは責任を持たない） • OSから下はアマゾンが責任を持つ • 独特な冗長化設計 • リージョンとアベイラビリティゾーン 16
17. 17. リージョンとアベイラビリティゾーン • リージョン（Region） • 一つの地域に置かれ、システム的に独立したまとまり • 「東京」「オレゴン」「北カリフォルニア」 • アベイラビリティゾーン（AZ） • 1つのリージョン内に複数設置されたまとまり • 一つの故障が複数のAZで併発しないように分離 • 個別のデータセンターを想定 17
18. 18. AWSでの冗長化の基礎 同じ役割のサーバを、各AZで半々に設置 18 ap-northeast-1a ap-northeast-1c Web Web DBDB ap-northeast-1
19. 19. AWSでの冗長化の基礎 • 「サーバ」という枠がないもの • Elastic Load Balancer （ロードバランサー） • DynamoDB （NoSQLデータベース） • などなど • これらはAZを意識せずに冗長化されている • これらの活用が運用を楽にする勝利の鍵 19
20. 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. 21. サーバインフラのコード化 • 「Infrastructure as Code」 • サーバ構成をコード（具体的にはJSONやRubyベースの DSLなど）で実装し、それをもとにAPIをたたいて展開 21
22. 22. HashiCorp • クラウドを管理するツールの開発会社 • OSSでツールを提供 • Vagrant、Packer、Terraform、Serf、Consul、Vault…… 22
23. 23. Terraform • AWSやAzureの構成をコード化 • コードに合わせて必要なサーバやコンポーネントを作成 • 不必要になったら削除 • JSONで書く • 今回はTerraformでAWSを操作してもらいます 23
24. 24. Terraformの使い方 • 公式ドキュメントのIntroduction参照 • https://www.terraform.io/intro/getting-started/install.html • DESTROY INFRASTRUCTUREまででOK 24
25. 25. 演習の準備 • Slackの準備 • seccamp Slackに登録 • ユーザ名を教えてください • private channneに招待します • GitHubの準備 • GitHubのユーザが無い人は登録 • ユーザ名を教えてください • プライベートレポジトリに招待します。 • 別にプライベートレポジトリが必要になったら声を掛けてください。 25
26. 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. 27. 前半おさらい • Terraform • ネットワーク構成などの自動化 • Docker • アプリケーションを丸ごとパッケージ • DockerHubで共有できる 27
28. 28. 後半
29. 29. 後半のゴール • Dockerでアプリを立ち上げてみる • サーバレスアーキテクチャに触れてみる
30. 30. Docker • アプリケーションコンテナの実行環境＋α 30
31. 31. アプリケーションコンテナ • アプリケーションの実行環境をパッケージにしたもの • ファイルシステム一式 • OS環境 • 必要なライブラリ・ミドルウェア • アプリケーション本体 • コンテナ起動時に実行するコマンドライン • 外部に公開する(LISTENする)TCPポート番号 • 外部と共有するファイルシステムのパス 31
32. 32. Docker • アプリケーションコンテナの実行環境＋α • DockerHubから取ってきて立ち上げる • 複数のコンテナを同時に管理する docker-compose • その他様々な管理ツールの集合体 32
33. 33. 演習 #02 • 先ほどのAmazonLinux上に、Dockerをインストール • Dockerでオープンソースのアプリを動かしてみる • http://qiita.com/y_hokkey/items/406b5a8c4bc15354d069 • このあたりから適当に選んでください。 参考までに「Reichat」の作者はセキュキャン勢です。 • ELB経由で見えるようにする • （もう1台はいったんLBから抜いてください） 33
34. 34. サーバレスアーキテクチャ • 最近流行りのキーワード 34
35. 35. 二つのサーバレスアーキテクチャ • アプリケーション実行環境としてのサーバレス • アプリケーションサーバという役割としてのサーバレス
36. 36. サーバレスなアプリケーション実行環境 • 「フルマネージドなPaaS」の発展系 • 短時間で起動する • 実際の実行時間で課金される • 利用者にとって「サーバ」という管理単位がなくなる
37. 37. 「アプリケーションサーバ」レス • モノリシックな「アプリケーションサーバ」 • デーモンとして常に起動してポートをLISTEN • リクエストをハンドリング • バッチ処理なども • 細かい「マイクロサービス」の集合に分割 • 一つの大きな「アプリケーションサーバ」が消失
38. 38. リアクティブアーキテクチャ リアクティブ宣言：近代的なシステムを実現するための設計原則 1. 即応性（実現したい価値） • システム全体として素早く、かつ安定した応答時間を保つ。 2. 耐障害性（非機能要件） • 障害が発生しても、それをコンポーネント内部に影響を隔離することで、システム全体としての即応性を保つ。 3. 弾力性（非機能要件） • 負荷の増減があっても、ボトルネックを排除し、割り当てるリソースを調整することで、即応性を保つ。 4. メッセージ駆動（アーキテクチャ構成要件） • 各コンポーネント間を、非同期なメッセージ配信で疎結合に保つ。
39. 39. リアクティブアーキテクチャ • 超ざっくり言うと、 • 小さなプログラムを • メッセージ駆動で • 繋いでいく • というアーキテクチャが良い、というものです。 39
40. 40. 演習 • AWS LambdaのBlueprintから一つ動かしてみる • hello-world系を除く • おすすめはslack-echo-command 40
41. 41. 発表 • 9人それぞれ、 • どこまでできたか • どこで苦労したか • どんな発見があったか • それぞれ3分くらいで発表してください。
42. 42. 後半おさらい • サーバレスアーキテクチャ • リアクティブシステム • AWS Lambda • Docker • アプリケーションを丸ごとパッケージ • DockerHubで共有できる 42