インフラセキュリティ
ブートキャンプ
株式会社WHERE
IoT基盤センター サービスプロデューサー
兼 情報システム室 インフラエンジニア
仲山 昌宏 ( @nekoruri )
講師プロフィール
• 仲山昌宏
• いわゆるインフラエンジニア+ウェブアプリ開発者
• 秋葉原生まれ大手町育ちの
歌って踊れる江戸っ子インフラエンジニア
• 株式会社WHERE
IoT基盤センター サービスプロデューサー
兼 情報システム室 イ...
経歴
• 2003-09~2005-03 大学院ネットワーク管理
• 2004-03~2010-06 WIDE Project irc.fujisawa.wide.ad.jp運用
• 2004-09~2005-10 国際大学GLOCOM (研究...
主なスキルセット
• システム設計
• クラウドとIoTデバイス組み合わせて
良い感じのシステム
• ウェブアプリの内部アーキテクチャ
• アプリケーション開発
• メインはサーバサイド
Perl、Ruby、Python、JS、PHP
• 過去...
この講義の目的
• セキュアなWebサービスインフラの構築・運用技術
• クラウド時代のサービス運用のポイント
• コードで管理されたサーバインフラの運用
• アプリケーションコンテナの活用
• サーバレスアーキテクチャ
• 負荷試験
5
進め方
• 基礎知識・ポイントの解説
• グループワーク
• 3人1グループでシステムを一つ作ってもらいます
• seccamp Slackでプライベートグループを作り、
作業内容を逐次そこに報告してください
• 最後に個人ごとに各自3分くらい...
サービスの運用とは
• 目的:
• ITを使って「お金を稼ぐ」
• 手段:
• お客さんにサービスを提供し、その対価を受け取る
(直接部門)
• 従業員にサービスを提供し、生産性を向上させる
(間接部門)
7
サービスの価値
• 使いたいときに使える(落ちない)こと
• いわゆる「サービスの品質」
• そもそも:
• サービスの内容がお客さんの期待を満たすこと
8
サービスの価値
• 使いたいときに使える(落ちない)こと
• いわゆる「サービスの品質」
• そもそも:
• サービスの内容がお客さんの期待を満たすこと
し続けること
9
サービスインフラの使命
• サービスの価値を利用者に届け続ける
• 新しい機能をすぐに届ける
• 既存の機能も安定して届け続ける
• クラウドの活用で実現
10
DevOps
• 過去:
• 新しい機能をすぐに届ける → 開発者(Dev)の仕事
• 既存の機能も安定して届け続ける → 運用者(Ops)の仕事
• 新しい機能に不具合が多いとシステムは安定しない
⇒ DevとOpsで利害の対立、意思決定の分...
クラウドのサービス分類
• いわゆる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つのリージョン内に複数設置されたま...
AWSでの冗長化の基礎
同じ役割のサーバを、各AZで半々に設置
18
ap-northeast-1a ap-northeast-1c
Web Web
DBDB
ap-northeast-1
AWSでの冗長化の基礎
• 「サーバ」という枠がないもの
• Elastic Load Balancer (ロードバランサー)
• DynamoDB (NoSQLデータベース)
• などなど
• これらはAZを意識せずに冗長化されている
• こ...
Amazon VPC
• AWS内に「自分のネットワーク」を確保する枠組み
• あえて作らなくても「デフォルト」のVPCが存在する
• VPCのIPアドレスブロック 例:10.0.0.0/16
• AZごとのサブネット 例:10.0.1.0/2...
サーバインフラのコード化
• 「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 INFRASTRUC...
演習の準備
• Slackの準備
• seccamp Slackに登録
• ユーザ名を教えてください
• private channneに招待します
• GitHubの準備
• GitHubのユーザが無い人は登録
• ユーザ名を教えてください
...
演習 #01
• Terraformで、以下をやってみる
• VPCを作成
• VPC内部にサブネットを二つ作成
• Internet Gateway、Route table、Route table associationを追加
• セキュリテ...
前半おさらい
• Terraform
• ネットワーク構成などの自動化
• Docker
• アプリケーションを丸ごとパッケージ
• DockerHubで共有できる
27
後半
後半のゴール
• Dockerでアプリを立ち上げてみる
• サーバレスアーキテクチャに触れてみる
Docker
• アプリケーションコンテナの実行環境+α
30
アプリケーションコンテナ
• アプリケーションの実行環境をパッケージにしたもの
• ファイルシステム一式
• OS環境
• 必要なライブラリ・ミドルウェア
• アプリケーション本体
• コンテナ起動時に実行するコマンドライン
• 外部に公開する...
Docker
• アプリケーションコンテナの実行環境+α
• DockerHubから取ってきて立ち上げる
• 複数のコンテナを同時に管理する docker-compose
• その他様々な管理ツールの集合体
32
演習 #02
• 先ほどのAmazonLinux上に、Dockerをインストール
• Dockerでオープンソースのアプリを動かしてみる
• http://qiita.com/y_hokkey/items/406b5a8c4bc15354d06...
サーバレスアーキテクチャ
• 最近流行りのキーワード
34
二つのサーバレスアーキテクチャ
• アプリケーション実行環境としてのサーバレス
• アプリケーションサーバという役割としてのサーバレス
サーバレスなアプリケーション実行環境
• 「フルマネージドなPaaS」の発展系
• 短時間で起動する
• 実際の実行時間で課金される
• 利用者にとって「サーバ」という管理単位がなくなる
「アプリケーションサーバ」レス
• モノリシックな「アプリケーションサーバ」
• デーモンとして常に起動してポートをLISTEN
• リクエストをハンドリング
• バッチ処理なども
• 細かい「マイクロサービス」の集合に分割
• 一つの大きな「...
リアクティブアーキテクチャ
リアクティブ宣言:近代的なシステムを実現するための設計原則
1. 即応性(実現したい価値)
• システム全体として素早く、かつ安定した応答時間を保つ。
2. 耐障害性(非機能要件)
• 障害が発生しても、それをコンポ...
リアクティブアーキテクチャ
• 超ざっくり言うと、
• 小さなプログラムを
• メッセージ駆動で
• 繋いでいく
• というアーキテクチャが良い、というものです。
39
演習
• AWS LambdaのBlueprintから一つ動かしてみる
• hello-world系を除く
• おすすめはslack-echo-command
40
発表
• 9人それぞれ、
• どこまでできたか
• どこで苦労したか
• どんな発見があったか
• それぞれ3分くらいで発表してください。
後半おさらい
• サーバレスアーキテクチャ
• リアクティブシステム
• AWS Lambda
• Docker
• アプリケーションを丸ごとパッケージ
• DockerHubで共有できる
42
Nächste SlideShare
Wird geladen in …5
×

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

2.334 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

インフラセキュリティブートキャンプ #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

×