クラウドセキュリティ基礎 ＠セキュリティ・ミニキャンプ in 東北 2016 #seccamp
649 Views
December 01, 16
スライド概要
クラウドセキュリティ基礎
＠セキュリティ・ミニキャンプ in 東北 2016
秋葉原生まれ大手町育ちの歌って踊れる江戸っ子インフラエンジニア。 0と1が紡ぐ「ゆるやかなつながり」に魅せられ早20年、 SNSとCGMの力で世界を幸福にするのがライフワーク。 市民、幸福は義務です。 あなたは幸福ですか？
関連スライド
各ページのテキスト
クラウドセキュリティ基礎 ＠セキュリティ・ミニキャンプ in 東北 2016 株式会社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 ↓
経歴 • 2003-09～2005-03 大学院ネットワーク管理 • 2004-03～2010-06 WIDE Project irc.fujisawa.wide.ad.jp運用 • 2004-09～2005-10 国際大学GLOCOM (研究アシスタント) SNS CGM • 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 (測位技術スタートアップ) ⬅今ここ ソーシャルゲーム
主なスキルセット • システム設計 • クラウドとIoTデバイス組み合わせて 良い感じのシステム • ウェブアプリの内部アーキテクチャ • アプリケーション開発 • メインはサーバサイド Perl、Ruby、Python、JS、PHP • 情報システム • 社内ITシステムの設計、運用 • 情報セキュリティマネジメント • サーバ/ネットワーク運用 • サーバHW（特にストレージ）周り • IPネットワーク • 過去にはWindowsとかも • 最近IoTデバイスの内蔵マイコンにも 手を出し始めた • 「必要があればなんでもやる」 5
アンケート 1. クラウドってなんとなく知ってる？ 2. サーバ管理ちょっとでもやったことある？ 6
この講義の目的 • クラウド時代のWebシステムについて • サーバ設計、構築、運用技術の基礎 • 「クラウドを使う」とはどういうことか • サービスの無停止とスケーラビリティを実現する設計 • クラウドのさらなる活用 • 演習 7
サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ 8
前職の話が分かりやすいと思うので、 CA社を例に挙げて説明します。 経歴 • 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 ↓
株式会社サイバーエージェント • 「アメーバで検索検索♪」の会社 • 半分が広告事業 • 広告の配信システム • 広告の代理業 • 残りの半分がゲーム＋メディア • 「グラブル」「デレステ」 • アメブロ、AbemaTV https://www.cyberagent.co.jp/ir/about/factsheet/ 10
サービスの運用とは 毎分26万円、稼ぎ時ならその何倍か 安いような高いような…… • 1時間サービスが止まったときの被害はおいくら？ • 2016年4Qのゲーム事業売上高：345億円（四半期決算） （2016/07/01～2016/09/30：92日間） • 1時間あたり1,563万円（1分あたり26万円） 11
サービスの運用とは 「障害時の損失」は、 「普段稼いでいる金額」でもあります。 • 1時間サービスが止まったときの被害はおいくら？ • 2016年4Qのゲーム事業売上高：345億円（四半期決算） （2016/07/01～2016/09/30：92日間） • 1時間あたり1,563万円（1分あたり26万円） • ピークタイム（稼ぎ時） • 期間限定イベントのラストスパート • 年始めのおみくじ代わり • 月初（キャリア決済の限度額がクリア） 12
サービスの運用とは 運用とは、 サービスの価値を届け続けることです。 • 目的： • ITを使って「お金を稼ぐ」 • 手段： • お客さんにサービスを提供し、その対価を受け取る （直接部門） • 従業員にサービスを提供し、生産性を向上させる （間接部門） 13
サービス運用の価値 • サービスの品質 • サービスの内容がお客さん の期待を満たすこと • サービスの稼働率 • 使いたいときに使える （落ちていない）こと ＜時間単価＞ × ＜稼働時間＞ 14
サービス運用の価値 • サービスの品質 • サービスの内容がお客さん の期待を満たすこと • • • • 便利、楽しい 需要を満たす 不具合が少ない レスポンスが速い • サービスの稼働率 • 使いたいときに使える （落ちていない）こと • 止まらない ＜時間単価＞ × ＜稼働時間＞ 15
ウェブ業界の特徴 • 「何もかもが速い」 • 流行るのも一瞬 • 廃れるのも一瞬 16
ウェブ業界の特徴 • 「何もかもが速い」 • 流行るのも一瞬 • 廃れるのも一瞬 流行ったらそれを逃さず「伸ばす」 • 状況に応じてシステムを最適化し続けることが重要 • DevOps、継続的デリバリー • 新技術を積極的に投入 • 廃れたら素早く方針転換、もしくは割り切って廃止 17
インフラ的なつらさ もちろん「金の弾丸」にも限界はあります • 流行れば大量のサーバがすぐに必要になる • チューニングには時間が掛かり限界もある • とにかくサーバ追加で時間を「稼ぐ」（通称：金の弾丸） • 廃れればどんどん縮小させる • 縮小しきれない過剰投資は「損失」でしかない • 新しい技術導入 • プロジェクトやリリース時期によってサーバ環境がバラバラ 18
それクラウドでできるよ 19
クラウドコンピューティング https://www.ipa.go.jp/files/000025366.pdf 20
イメージしづらいかもしれませんが、 要点は黄色の部分です。 クラウドコンピューティング https://www.ipa.go.jp/files/000025366.pdf 21
クラウドコンピューティング • 要点 • 共用されたリソースプールから • いつでもどこからでもネットワーク経由で • 必要な分だけをすぐに利用できる 22
クラウドの特徴 NISTの定義はあくまで「一つの定義」ですが、 それなりに広まっているものです。 NIST（米国国立標準技術研究所）による基本特徴の整理 1. オンデマンド・ セルフサービス APIでなんでもできる 2. 幅広いネットワークアクセス ネットワーク経由でできる 3. リソースの共用 共用する潤沢なリソースプールがある 4. スピーディな拡張性 すぐに利用可能 5. サービスが 計測可能であること 自らの利用量が適切に計測（されて課金される） 23
クラウドの分類 パブリックも、プライベートも、あるんだよ。 運用方法による分類 • パブリッククラウド • 大規模な事業者が運用して数多くの利用者が共有 • AWSとかAzureとかいろいろ • プライベートクラウド • 社内で単独で運用 • YahooとかCyberAgentとか 24
パブリッククラウド 「責任共有モデル」はAmazon用語ですが、 考え方はだいたい皆同じです。 • 大規模な事業者 • 豊富なリソースにもとづく最適化 • 膨大な開発能力にもとづく多種多様な機能 • 責任共有モデル • ざっくりOSから下は事業者がセキュリティを担保 • 各種セキュリティガイドラインへの準拠 • むしろベストプラクティスが実装された環境 • OSとその上は利用者がセキュリティを自力で担保 25
プライベートクラウド • 既存の自前でデータセンタ借りてサーバ置くモデル • OpenStackなどのクラウドコントローラでクラウド化 • 基本機能はAmazon等と似たようなことができる • 多種多様な機能は少ない • プライベートでの差別化 • 既にノウハウや購買力を持つ場合 • システム間が密結合（消極的理由） • これらを維持しつつ、クラウドや仮想化のメリットを享受 • 社内の「クラウド事業者」部門 26
「所有」から「利用」へ これが「クラウド」による変化の本質です。 • サーバを所有しない • サービス部門は物理的なサーバを直接持たない • サーバやデータセンター、ネットワークの管理をしない • サーバは利用する • 必要な時間だけ、サーバの利用権を買う（借りる） • その道の匠が設計した素敵なサーバ環境を利用できる 27
クラウドのサービス分類 IaaSとPaaSの定義は既に「古い」ものですが、 前半ではいわゆるIaaSを主に対象とします サービス形態による分類 • SaaS • 具体的なアプリケーションとして提供される。 • DropboxとかGmailとか • PaaS • アプリケーションが動く環境が用意される。 • Herokuとか • IaaS • サーバ一式が用意される。いわゆるレンタルサーバに近い。 • ネットワーク機能（FW、LB等）も提供されたりする。 28
クラウド(IaaS)でサーバを確保 • 自由なサーバの追加・削除が可能になる • すぐ（数分程度）にサーバが増やせる！ ↔ これまでは最大想定分だけのサーバを事前に用意 ↔ 想定を超えるとすぐに対応ができない • 要らないサーバはいつでも捨てられる！ ↔ 資産の耐用年数（5年程度）を使い切れない ↔ 挑戦的なサービスをリリースできない 29
具体的にイメージしてみよう • サーバはすぐに確保・削除できる ↓ • 作ったサーバに環境構築してすぐ本番投入したい • 本番投入中のサーバでもすぐに消したい 30
ポイント1 作ったサーバに環境構築してすぐ本番投入したい • サーバの構築や運用の手間はかわらない • ミドルウェア入れて設定ファイルを変更 • アプリの動作に必要なライブラリも入れる • 最新のアプリケーションをデプロイ（設置） • アプリケーション設定（DB認証情報等）も設置 • アプリケーションのプロセスを起動 31
ポイント2 本番投入中のサーバでもすぐに消したい • サーバ内に記録されたデータはどうする？ • データベース • セッション情報 • アクセスログ、エラーログ、デバッグログ • システムログ（syslog, イベントログ） • 一時的に手で入れたテスト用設定 32
クラウド時代の考え方 クラウドのメリットは、 考え方を整理することで最大化します！ • サーバの設計方法も合わせていこう！ • 構築や運用が楽になる方法を作る • システム全体のデータの記録方法を見直す ※物理サーバの考えを引っ張るとむしろ高く付くことも 33
「ペット」から「家畜」へ 10000匹のペットなんて 面倒見切れません • これまで：サーバ＝ペット🐕🐈 • 1台1台名前を付けて、手間を掛けて育てていく • 少しおかしくなっても直して死ぬまで面倒を見る • これから：サーバ＝家畜🐖🐓 • 集団の役割だけを見て、1台ずつの個別の面倒は見ない • おかしくなったら殺す 34
「メリハリ」を付けよう • Statelessサーバ 責務をはっきりと分割して、 メリハリ付けて管理しましょう。 🐖🐓 • アプリケーションを動かすサーバ • データを中に一切保存せず、コピーすれば動くレベル • いつでも追加/削除しやすい状態を保つ • Statefulサーバ 🐕🐈 • データベース、ログ • 追加/削除がしづらいので死ぬ気で守る • スペックアップや分散DBの利用でスケーラビリティ確保 35
Statelessサーバの指針 • Twelve-Factor App • http://12factor.net/ja/ • （いくつか宗教的な項目もあるものの） 今までに提起された最適解の「まとめ」 36
全て重要なのですが、時間が足りないので、 個人的に特徴的と思うポイントのみ…… Twelve-Factor App I. コードベース VII. ポートバインディング II. 依存関係 VIII. 並行性 III. 設定 IX. 廃棄容易性 IV. バックエンドサービス X. 開発/本番一致 V. ビルド、リリース、実行 XI. ログ VI. プロセス XII. 管理プロセス 37
Twelve-Factor App I. コードベース バージョン管理されている1つのコードベースと 複数のデプロイ • 1つのコードベース • アプリケーション全体が一つのレポジトリ • それ以外は、依存ライブラリか参照先の外部システム • 複数のデプロイ • 本番環境、ステージング環境、開発環境 • 全ての変更をきちんと記録・追跡 38
Twelve-Factor App III. 設定 設定を環境変数に格納する • デプロイごとに異なる設定 • DB接続先とかドメイン名とか • アプリ本体に設定を保存しない • 起動時に動的に設定できるようにする • あたらしい種類のデプロイをすぐ作れるようにする • ソースコードを完全に同一にできる 39
じゃあ、Statefulサーバは？ 3番目の選択肢の登場で できることが増えてきました 「銀の弾丸」は無いが、現実的な選択肢は増えている。 1. スケールアップで対応（金の弾丸） • 「Fusion-ioは甘え」でもいいじゃないか 2. 分散DB • Cassandra、HBase、MongoDBとかとか 3. すごいストレージサービスを使う • Amazon DynamoDBやGoogle BigQuery 40
クラウド時代のサーバ設計 • Statelessサーバ 🐖🐓 • アプリケーションを動かすサーバ • データを中に一切保存せず、コピーすれば動くレベル • いつでも追加/削除しやすい状態を保つ • Statefulサーバ 🐕🐈 • データベース、ログ • 追加/削除がしづらいので死ぬ気で守る • スペックアップや分散DBの利用でスケーラビリティ確保 41
Blue-Green Deployment • もう1セット（Green）作って 古い方（Blue）を捨てよう！ 動作が怪しかったらすぐ戻せるのが最大の特長 緊急の脆弱性対応にも有用 ③問題が無ければ 古い環境（Blue）を廃棄 サーバー サーバー L B ②Greenに アクセス先を 切り替え サーバー ｃ DB 共通環境 サーバー ①新しいバージョン（Green）の 環境を構築 42
クラウド時代のサーバ設計 • Statelessサーバ 🐖🐓 • アプリケーションを動かすサーバ • データを中に一切保存せず、コピーすれば動くレベル • いつでも追加/削除しやすい状態を保つ • Statefulサーバ 🐕🐈 • データベース、ログ • 追加/削除がしづらいので死ぬ気で守る • スペックアップや分散DBの利用でスケーラビリティ確保 43
Statefulサーバのセキュリティ運用 • 本当はつらい脆弱性対応 • その修正バージョン、全く動作同じ？ • 動作確認きちんとやって修正、反映するのはそれなりに手間 • かといって、世の中の脆弱性はたくさん…… 44
脆弱性の評価 セキュリティの運用は、 いかに「人の判断」をシステムに落とし込んで 自動化するかが大事です。 • きちんと脆弱性を評価して優先度を決めよう！ • 実際に起こりづらい脅威に対する脆弱性なら優先度低い • 評価のためのフレームワークやツール • 共通脆弱性評価システム：CVSS v2 https://www.ipa.go.jp/security/vuln/CVSS.html • 脆弱性チェックの自動化ツール：Vuls https://github.com/future-architect/vuls CVSSスコアで危険なものだけ通知できる ※同種にOpenVASやAmazon Inspectorなどがある 45
CVSS v2の基準 • 基本評価基準 (Base Metrics) • 脆弱性そのものの特性 • 機密性、完全性、可用性への影響、 攻撃のしやすさ（ネットワーク経由の攻撃可否など） • 現状評価基準 (Temporal Metrics) • 今どれぐらいやばいか • 環境評価基準 (Environmental Metrics) • 二次被害の度合いとかその他の影響範囲 46
CVSS実例 • CVE-2014-0160 Heartbleed • Base Score: 5.0 • CVE-2014-3566 POODLE • Base Score: 4.3 • CVE-2014-6271 Shellshock • Base Score: 10.0 • CVE-2015-0235 GHOST • Base Score: 6.8(RedHat) / 10.0(NVD) 47
クラウドの管理 「人間の操作の数＝意志決定した数」 であるべきで、それ以外は余計なのです。 • コントロールパネル • ブラウザで人がログイン • マウスでクリッククリッククリック…… • つらい • 人間は必ずミスをする • そもそも人の意志決定の余地は少ない 48
APIによるアクセス クラウドの最大の特長です！ • サーバ環境をAPIで操作可能 • APIの認証情報（アクセスキー）を利用 • コントロールパネルとほぼ同じ操作が可能 • APIの利用 • APIを利用するライブラリやCLIコマンド • REST API • 自動処理が可能に！ 49
オフレコ（APIの悪用事例） 50
APIが万能である故の問題 Two-Factor Appにもありましたが コードに直接認証情報を書いてはいけません • APIの認証情報があれば何でもできてしまう • 自動化プログラムとかにカジュアルに組み込みやすい • なにかされたことにすぐに気付きにくい • 潤沢なリソースが利用可能 • めっちゃくちゃ速いサーバ • めっちゃくちゃ大きいストレージ • しかも一気にたくさん作れる（リミットはある） 51
クラウドの管理 • 適切なアクセス制御 • 本当にその人に必要な作業しか実行させない • 最小権限の原則 • 操作内容の監査（記録） • 誰がその作業をしたのかを記録 • あやしい行動をチェックできる 52
最小権限の原則 覚えて帰って欲しいキーワード • 情報セキュリティで最も重要な原則 • 必要最小限の権限だけを用意する • 例：アクセスキーの権限を最低限にする • 社外のIPアドレスから操作する権限は本当に必要？ • サンパウロでサーバ作成する権限は本当に必要？ • 1時間1400円もするサーバを作成する権限は(同上) 53
AWS Identity and Access Management （IAM） • アクセス権限を管理する仕組み • AWSは元々は1アカウント＝1認証情報（email/password) • ユーザやグループを作成して、権限を細かく割り当て可能 • より抽象化した「ロール」への割り当てもできる • アクセス元IPアドレスなども設定可能 54
AWS CloudTrail • 操作内容を記録する • Amazon S3（ストレージサービス）に保管 • 別のAWSアカウントにも送り込める • 外部の分析サービスとの連携も可能 55
前半のまとめ • クラウドコンピューティング • ペットから家畜へ、StatelessサーバとStatefulサーバ • APIの利用と権限の管理 56
― 休憩 ― 57
後半の目的 • 前半 • クラウドでサーバを借りて上手くやる • 後半 • より深くクラウドらしい使い方 • みんなだいすき演習 58
クラウドのサービス分類 • いわゆるIaaS • サーバ単位で借りる • いわゆるPaaS • 機能単位で借りる • Heroku、AWS Lambdaのような実行環境 • Amazon RDSやAWS IoTのような具体的な機能 59
IaaSの利用 • サーバを自前で用意せずクラウドで借りる • システム全体を大きく帰ることなく、 スケールアップ（性能を上げる） スケールアウト（台数を増やす） のようなメリットを得やすい 60
PaaSの活用 • 「ありもの」を組み合わせる • 餅は餅屋モデル • 「EC2使ったら負け」 • システム自体の変化が強いられる • 一見高く見えることも • これまで見えていなかったコスト・リスクの可視化 • 上手くはまる＝最適化できると画期的なコスト減も 61
Amazon Web Services (AWS) • 世界で一番大規模なクラウド事業者 • 対抗馬はMicrosoft Azure • シェアはまだ大きな差がある • 機能面では追いつきつつある（部分的に先行） 62
うはｗｗｗサービス多すぎｗｗｗｗｗｗ 63
AWSのポイント • 責任共有モデル • OSから上を利用者が責任を持つ （アマゾンは責任を持たない） • OSから下はアマゾンが責任を持つ • 独特な冗長化設計 • リージョンとアベイラビリティゾーン 64
リージョンとアベイラビリティゾーン • リージョン（Region） • 一つの地域に置かれ、システム的に独立したまとまり • 「東京」「オレゴン」「北カリフォルニア」 • アベイラビリティゾーン（AZ） • 1つのリージョン内に複数設置されたまとまり • 一つの故障が複数のAZで併発しないように分離 • 個別のデータセンターを想定 65
AWSにおける冗長化の基本 同じ役割のサーバを、各AZで半々に設置 ap-northeast-1a Web DB ap-northeast-1 ap-northeast-1c Web DB 66
SLAでみる冗長化設計 各社のSLAを比較してみると サービスの設計思想が見えて面白いですよ。 https://aws.amazon.com/jp/ec2/sla/ サービス利用者がインスタンスを実行している 複数のAvailability Zoneが、 サービス利用者にとって「使用不能」となること ＝ 複数のAZにまたがってサーバ置いていないと、 落ちても知らないよ？ 67
AWSでの冗長化の基礎 • 「サーバ」という枠がないもの • Amazon S3 （ファイルストレージ） • Elastic Load Balancer （ロードバランサー） • DynamoDB （NoSQLデータベース） • などなど • これらはAZを意識せずに冗長化されている • これらの活用が運用を楽にする勝利の鍵 68
サーバインフラのコード化 • 「Infrastructure as Code」 • サーバ構成をコード（具体的にはJSONやRubyベースの DSLなど）で実装し、それをもとにAPIをたたいて展開 • プログラミング的手法で改善が可能 • Git等でのリビジョン管理、レビュー • デプロイツールの活用 • 自動テスト 69
Terraform • AWSやAzureの構成をコード化 • コードに合わせて必要なサーバやコンポーネントを作成 • 不必要になったら削除 • JSONで書く • 信頼と安定のHashicorp 70
HashiCorp Hashicorpのビジョンは、 「クラウドと自動化」を語る上で たいへん参考になるものです。ぜひご一読。 • クラウドを管理するツールの開発会社 • OSSでツールを提供 • Vagrant、Packer、Terraform、Serf、Consul、Vault…… • Hashicorpのビジョン「The Tao of HashiCorp」 • 原文: https://www.hashicorp.com/blog/tao-of-hashicorp.html • 日本語訳: http://pocketstudio.jp/log3/2015/03/14/the-tao-of-hashicorp/ 71
Terraformの設定例 resource "aws_instance" "bastion" { tags { Name = "bastion" } ami = "${data.aws_ami.bastion.id}" instance_type = "t2.micro" vpc_security_group_ids = [ "${aws_security_group.internal.id}", "${aws_security_group.bastion.id}“ ] subnet_id = "${aws_subnet.shared-vpc-subnet-a.id}" associate_public_ip_address = true } 72
Infrastructure as Codeの目的 • 「プログラミングの手法」をインフラ管理に適用 • Git等によるリビジョン管理、Pull-Requestレビュー • テスト駆動 • 再利用しやすいDSL（ドメイン固有言語）による記述 • Terraformでかなりの部分を実現 • AWS自身のCloudFormationなどもある • サーバ「内部」の管理は……？ 73
サーバの構成管理 • サーバの環境（アプリケーションの実行環境）を管理 • OSの設定 • ミドルウェアの導入 • ミドルウェアの設定ファイルの設置 • アプリケーションの設置に必要な調整 74
サーバ構成管理の歴史 1. 職人芸 2. 手順書 3. シェルスクリプト 4. 構成管理ツール 5. アプリケーションコンテナ＋軽量なツール 75
構成管理ツール • Puppet、Chef、Ansible • 主な違い • 対象サーバのリストの管理方法 • 対象サーバへのソフトウェア導入要否 （≒SSHだけで遠隔操作できるか） • 構成を記述するDSL Puppet=独自DSL、Chef=内部DSL(Ruby)、Ansible＝YAML • 冪等性の担保（差分を計算して適用） 76
アプリケーションコンテナの登場 • 対象サーバの上で直接アプリケーションを実行 ↓ • 仮想化機能を使って、アプリケーションのパッケージ 「コンテナ」の中でアプリケーションを実行 77
アプリケーションコンテナ • アプリケーションの実行環境をパッケージにしたもの • ファイルシステム一式 • OS環境 • 必要なライブラリ・ミドルウェア • アプリケーション本体 • コンテナ起動時に実行するコマンドライン • 外部に公開する(LISTENする)TCPポート番号 • 外部と共有するファイルシステムのパス 78
Docker • アプリケーションコンテナの実行環境＋α • 仮想化機能の上でアプリケーションを実行 • DockerHubからコンテナイメージを取ってくる • 複数のコンテナを同時に管理する docker-compose • その他様々な管理ツールの集合体 79
コンテナ時代の構成管理 • ゼロからアプリケーションを動かせば良い • 冪等性を考えたりとかしなくて良くなった • 実はそれシェルスクリプトでよくね？ • DB接続先などは、コンテナのイメージとして配るのでは無 く、起動時に設定したい • シェルスクリプト（標準のDockerfile）小さなツール 80
アプリケーションPaaS（aPaaS） • より汎用な枠組み • アプリケーションの実行環境の準備、運用を、 全て自動化されたaPaaSに「おまかせ」 • Heroku、Amazon Beanstalk、Azure Web Apps • Dockerコンテナを動かせたりもする 81
サーバレスアーキテクチャ • 最近流行りのキーワード • Question: サーバ「レス」とは？ 82
二つのサーバレスアーキテクチャ • アプリケーション実行環境としてのサーバレス • システム全体における役割としてのサーバレス
サーバレスなアプリケーション実行環境 • 「フルマネージドなPaaS」の発展系 • 利用者にとって「サーバ」という管理単位をなくしたい • その筋のプロである「クラウド事業者」が、それぞれの方法 で適切に管理してくれる＝フルマネージド • 使う量（確保量）から使った量（使用量）へのシフト • 事前に「台数」の確保が不要 • 短時間で起動し、必要なだけ拡張 • 実際の実行時間で課金される 「確保量から使用量へ」は 「所有から利用へ」の先にあるものです。
サーバレスなアプリケーション実行環境 • 基本的には、高度に発達したアプリケーションPaaS • AWS Lambdaの例 • 1プロセスが利用する最大メモリ量を指定（例：256MB） • 100ミリ秒単位で、実際に消費した時間を課金 • 呼び出し頻度に応じて、自動的にプロセス起動数を管理 85
制約とメリット 「何でもできる」ことは良いとは限らず、 「良い制約」にうまく乗っかることが重要です。 • アプリケーションのプロセス起動・終了を任せる ⇒ プロセス内にデータを保存することができない 前半の「Stateless」サーバの考え方の徹底 • 「Stateless」という制約を受け入れることで、 「フルマネージド」というメリットが得られる 86
システム全体における役割としてのサーバレス 一つの大きな「アプリケーションサーバ」 ↓ クラウドが提供するコンポーネントの有効活用 ↓ 細かい「マイクロサービス」の組み合わせに分割
通信形態の大きな変化 LINE BotやIoT×ビッグデータ解析のような システムも、本質的に非同期にできています。 • 従来：リクエスト・レスポンスなどの同期型通信 • リクエストを受けたプログラムが、データベースへの読み書 きなど、レスポンスを返すまで全ての処理を担当 • 今後：非同期型通信が普及 • スマホアプリやWebSocket等の普及で、ブラウザまで含めて 非同期なシステムを作ることが増えてきた 88
サーバレスアーキテクチャの例 IoTデバイス SORACOM Funnel Kinesis Streams (AWS Lambda) Status Updater (AWS Lambda) Manager App API Gateway 管理者 Amazon S3 最新ステータス Cognito Identity 89
複雑なパターン • Amazon S3に動画ファイルをアップロード ⇒それをトリガにしてフォーマット変換を起動 ⇒変換が終わったら動画一覧を再生成 ⇒生成できたらCDNのキャッシュをクリア ⇒全部終わったら投稿者にメール • 複雑な機能はピタゴラ装置のように作る 90
リアクティブアーキテクチャ リアクティブ宣言：近代的なシステムを実現するための設計原則 1. 即応性（実現したい価値） • システム全体として素早く、かつ安定した応答時間を保つ。 2. 耐障害性（非機能要件） • 障害が発生しても、それをコンポーネント内部に影響を隔離することで、システム全体としての即応性を保つ。 3. 弾力性（非機能要件） • 負荷の増減があっても、ボトルネックを排除し、割り当てるリソースを調整することで、即応性を保つ。 4. メッセージ駆動（アーキテクチャ構成要件） • 各コンポーネント間を、非同期なメッセージ配信で疎結合に保つ。
リアクティブアーキテクチャ • 超ざっくり言うと、 • 小さなプログラムを • メッセージ駆動で • 繋いでいく • という非同期型アーキテクチャが良い、という考え方 92
リアクティブアーキテクチャ • 「ペットから家畜へ」を踏まえたアーキテクチャ メッセージ ワーカー ワーカー ワーカー ワーカー ワーカー ワーカー 93
リアクティブアーキテクチャ • 「ペットから家畜へ」を踏まえたアーキテクチャ メッセージ 他の誰かが実行 ワーカー ワーカー ワーカー ワーカー ワーカー ワーカー 94
サーバレス時代のセキュリティ • これまで • 一つの大きなアプリケーションの「中身」に侵入 • アプリケーションの実装方法の脆弱性 • これから • 小さなアプリケーション⇒実装レベルの脆弱性は減少 • コンポーネントの利用方法レベルの脆弱性 • ID管理に基づいたコンポーネント単位の認可がより重要に してほしい… 95
サーバレスアーキテクチャの本質 • 動かしたいのは「サービス」で「サーバ」ではない • Statelessという制約を受け入れることで、「サーバ」という 単位で管理する必要を無くした • フルマネージドなサービスの活用＝「餅は餅屋」 • サービスの実現のためのベストプラクティスの一つ 96
クラウドの活用方法のおさらい • 冗長化 • サーバインフラのコード化 • アプリケーションコンテナ（Docker） • サーバレスアーキテクチャ 97
演習 • AWSで実際にサービスを立ててみよう 1. 2. 3. 4. マネジメントコンソールへのログインを確認 Amazon S3にファイルをアップロードして公開 SSH鍵対を作成してAWSに登録 Amazon EC2でサーバを構築 5. 構築したサーバをCLIから見てみよう 6. 構築したサーバにログインしてAPIサーバを構築 7. S3に置いたHTMLからAPIを叩いてみる 8. ここまでの操作ログを見てみよう 98
1. マネジメントコンソールへのログインを確認 1. お渡ししたログイン情報のURLを開く 2. IDとパスワードを入力 3. マネジメントコンソールにログインできることを確認 4. 右上が「オレゴン」など東京以外になっていたら、 プルダウンメニューから東京に切り替え 99
2. Amazon S3にファイルをアップロードして公開 ここではAPIでの操作に触れてもらいます。 1. コマンドプロンプトからaws configure を実行し、以下のように入力 AWS Access Key ID [None]: ＜アクセスキーID＞ AWS Secret Access Key [None]: ＜シークレットアクセスキー＞ Default region name [None]: ap-northeast-1 Default output format [None]: json 2. aws s3 mbコマンドでバケット（ファイルの置き場所）を作成 aws s3 mb s3://seccamp1126-＜自分の名前＞ 3. aws s3 cpコマンドでファイルをアップロード（index.htmlは適当に用意） aws s3 cp index.html s3://seccamp1126-＜自分の名前＞/ --acl public-read 4. 以下のURLをブラウザで開いて、アップロードされたことを確認 http://s3-ap-northeast-1.amazonaws.com/seccamp1126-＜自分の名前＞/index.html 100
PuTTY版 3. SSH鍵対を作成してAWSに登録 (1) 1. スタートメニューから、「PuTTYgen」を起動 2. 「Generate」をクリックし、マウスぐりぐりしながら待機 3. Key commentに自分の名前をアルファベットで入力 Key passphraseとすぐ下のConfirmに自分が覚えるパスフレーズを入力 4. Save private keyをクリックし、ドキュメントに秘密鍵を保存 5. 保存した秘密鍵をダブルクリックして、パスフレーズを入力 6. 上のテキストボックス（Public key for pastingなんちゃら）に表示され ている公開鍵をメモ帳に張り付けて、ドキュメントに保存 101
TeraTerm版 3. SSH鍵対を作成してAWSに登録 (1) 1. デスクトップから、「TeraTerm」を起動 2. 設定メニューからSSH鍵生成を起動 3. 「生成」をクリックし、マウスぐりぐりしながら待機 4. パスフレーズとすぐ下のConfirmに自分が覚えるパスフレーズ入力 コメントに自分の名前をアルファベットで 5. 秘密鍵を保存をクリックし、ドキュメントに秘密鍵を保存 6. 公開鍵を保存をクリックし、ドキュメントに公開鍵を保存 102
3. SSH鍵対を作成してAWSに登録 (2) 1. マネジメントコンソールの左上から、EC2を開く 2. 左メニューの「キーペア」を開く 3. 「キーペアのインポート」をクリック 4. ファイル選択で先ほど保存した公開鍵のファイルを選択 5. キーペア名に名前をアルファベットで入力 103
4. Amazon EC2でサーバを構築 (1) 1. マネジメントコンソールの左上から、EC2を開く 2. 左メニューの「インスタンス」を開く 3. マシンイメージ（OSインストール済みのディスクデータ）を聞かれる ので、一番上の「Amazon Linux AMI」を選ぶ 4. インスタンスタイプは、t2.microを選ぶ 5. 「自動割り当てパブリック IP」が有効になっていることを確認して次の 手順へ 6. ストレージの追加はそのまま次の手順へ 104
4. Amazon EC2でサーバを構築 (2) 1. 「Add Tags」の画面で、Nameに名前をアルファベットで入力 2. セキュリティグループの設定で以下のように設定 • 新しいセキュリティグループを作成する • 元からある行を以下のように設定 タイプ：SSH 送信元：マイIP • ルールの追加をクリックし、追加された行を、 タイプ：HTTP 送信元：カスタム 0.0.0.0/0 3. 確認と作成をクリックし、次の確認画面で「作成」を実行 4. キーペアとして、先ほど登録した自分の名前のものを選択してインスタ ンスの作成 105
4. Amazon EC2でサーバを構築 (3) 1. 「次のインスタンスの作成が開始されました: i-99999999 」 のように表示されるので、i- ではじまるインスタンスIDをクリック 2. ステータスチェック欄が「✔」になるまで待機 右上の丸い矢印をクリックすると再読込します。 106
5. 構築したサーバをCLIから見てみよう 1. コマンドラインから以下のコマンドでEC2のインスタンス一覧が見られます。 aws ec2 describe-instances 107
PuTTY版 6. 構築したサーバにログインしてAPIサーバを構築 1. 「パブリックIP」に表示されたIPアドレスをメモ 2. PuTTYを起動し、上のIPアドレスを入力して接続 3. 「login as:」でログインユーザ名を聞かれるので「ec2-user」を入力 4. SSHで正しくログインできたことを確認 5. sudo yum update -y && sudo yum install httpd –y sudo service httpd start を実行してApacheをインストール 6. http://＜IPアドレス＞/ をブラウザで見られることを確認 7. sudo chown ec2-user /var/www/html 108
TeraTerm版 6. 構築したサーバにログインしてAPIサーバを構築 1. 「パブリックIP」に表示されたIPアドレスをメモ 2. TeraTermを起動し、上のIPアドレスを入力して接続 3. ログインユーザ名を聞かれるので「ec2-user」を入力し、 その下にパスフレーズを入力 「RSA/DSA/ECDSA/ED25519鍵を使う」を選択し、 秘密鍵ボタンで、さきほど保存した秘密鍵ファイルを指定 4. SSHで正しくログインできたことを確認 5. sudo yum update -y && sudo yum install httpd –y sudo service httpd start を実行してApacheをインストール 6. http://＜IPアドレス＞/ をブラウザで見られることを確認 7. sudo chown ec2-user /var/www/html 109
6. 構築したサーバにログインしてAPIサーバを構築
1. API結果を想定したJSONファイルを保存
/var/www/html/api.json
{"message":"Hello, Cloud!"}
2. クロスオリジン対策の設定ファイルを保存
sudoedit /etc/httpd/conf.d/cors.conf
<Directory "/var/www/html">
Header append Access-Control-Allow-Origin: "*"
</Directory>
3. sudo service httpd restart
110
7. S3に置いたHTMLからAPIを叩いてみる 1. 配布した index.html の中のIPアドレスをサーバのものに変更 2. これまでの手順を参考に、S3にアップロード 3. S3上にアップロードしたHTMLを開いてAPIが呼ばれたことを確認 http://s3-ap-northeast-1.amazonaws.com/＜バケット名＞/index.html 111
8. ここまでの操作ログを見てみよう 1. 左上のサービス一覧からCloudTrailを選択 2. 今までの操作履歴がどのように記録されているのかを確認する 112
演習のおさらい • EC2を使って、サーバを立ててみました • クラウドのサービス分類ではIaaSと呼ばれる • awsコマンドを使ってAPI経由で操作することも可能 • S3を使って、より楽にウェブサーバを立てました • サービス分類としてはPaaS • 便利でしょ？ • どんな記録が残るのか見てみました 113
まとめ • クラウド時代のWebシステムについて • サーバ設計、構築、運用技術の基礎 • 「クラウドを使う」とはどういうことか • サービスの無停止とスケーラビリティを実現する設計 • クラウドのさらなる活用 • 演習 114
最後に • 特にこの10年のインフラ業界は動きが早いです • クラウドが登場して（まだ）10年間 • 前提が変わり、ベストプラクティスが入れ替わる • 個人的には、 ・この10年で物理サーバからクラウド上の仮想サーバに ・今後10年でサーバという枠組みから解放 と予想しています • ツールレベルの盛衰は、一々取り上げるのも切りが無い • 動きが早い＝面白い！ 115
最後に • すぐに手を動かそう！ • 無料クーポン、無料枠を活用しよう（学生はより有利！） • 大きな機能もちょっとだけなら安くお試しできる！ • とにかくネタと機会を作って情報を発信しよう！ • 情報は活動する人の近くに集まる • ブログ等での情報発信 • 勉強会等での発表 • 同人誌等の制作、頒布 116