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