Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Masahiro NAKAYAMA, profile picture
Uploaded byMasahiro NAKAYAMA
3,690 views

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

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

Technology◦
Related topics:
Information Security•Cloud Computing Insights•
Downloaded 30 times
インフラセキュリティ ブートキャンプ 株式会社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