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

2.311 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
0 Kommentare
3 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
2.311
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
142
Aktionen
Geteilt
0
Downloads
27
Kommentare
0
Gefällt mir
3
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

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

×