Download as PDF, PPTX
![Terraformの設定例
74
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
}](https://image.slidesharecdn.com/20161106seccampcloudsecurity-161114134456/85/slide-74-320.jpg)
Uploaded byMasahiro NAKAYAMA
クラウドセキュリティ基礎
最新版はこちら ⇒ http://www.slideshare.net/nekoruri/20161126-cloud-security-aomori 2016-11-06 セキュリティ・ミニキャンプ in 北海道 2016 #seccamp
More Related Content
![[デブサミ2012]趣味と実益の脆弱性発見](https://cdn.slidesharecdn.com/ss_thumbnails/devsumi-hasegawa-120216203637-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[AWS Summit 2012] クラウドデザインパターン#1 CDP概要編](https://cdn.slidesharecdn.com/ss_thumbnails/aws-summit-cdp-01-121001104449-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[AWS Summit 2012] クラウドデザインパターン#8 CDP アンチパターン編](https://cdn.slidesharecdn.com/ss_thumbnails/aws-summit-cdp-08-121001111025-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[AWS Summit 2012] クラウドデザインパターン#7 CDP キャンペーンサイト編 (Wordpress)](https://cdn.slidesharecdn.com/ss_thumbnails/aws-summit-cdp-07-121002233247-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
クラウドセキュリティ基礎
- 1. クラウドセキュリティ 基礎 株式会社WHERE IoT基盤センター サービスプロデューサー 兼 情報システム室インフラエンジニア 仲山 昌宏
- 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. 主なスキルセット • システム設計 • クラウドとIoTデバイス組み合わせて 良い感じのシステム •ウェブアプリの内部アーキテクチャ • アプリケーション開発 • メインはサーバサイド Perl、Ruby、Python、JS、PHP • 過去にはWindowsとかも • 最近IoTデバイスの内蔵マイコンにも 手を出し始めた • 情報システム • 社内ITシステムの設計、運用 • 情報セキュリティマネジメント • サーバ/ネットワーク運用 • サーバHW（特にストレージ）周り • IPネットワーク • 「必要があればなんでもやる」 4
- 5. この講義の目的 • クラウド時代のWebシステムについて • サーバ設計、構築、運用技術の基礎 •サービスの無停止とスケーラビリティを実現する設計 • 継続的インテグレーション、高速なリリースサイクル • クラウドのさらなる活用 • Infrastructure as Code • アプリケーションPaaS • サーバレスアーキテクチャ 5
- 6.
- 7. 経歴 • 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 ↓
- 8. 株式会社サイバーエージェント • 「アメーバで検索検索♪」の会社 • 半分が広告事業 •広告の配信システム • 広告の斡旋 • 残りの半分がゲーム事業 • 「グラブル」 • 「デレステ」「モバマス」 • 残りがメディア事業 • アメブロ、AbemaTV 8 https://www.cyberagent.co.jp/ir/about/factsheet/
- 9. サービスの運用とは • 1時間サービスが止まったときの被害はおいくら？ • 2016年3Qのゲーム事業売上高：306億円（四半期決算） （2016/04/01～2016/06/30：91日間） •1時間あたり1,401万円（1分あたり23万円） • ピークタイム（稼ぎ時） • 期間限定イベントのラストスパート • 月初（キャリア決済の限度額がクリア） • 年始めのおみくじ代わり 9
- 10. サービスの運用とは • 目的： • ITを使って「お金を稼ぐ」 •手段： • お客さんにサービスを提供し、その対価を受け取る （直接部門） • 従業員にサービスを提供し、生産性を向上させる （間接部門） 10
- 11.
- 12. サービスの価値 • 使いたいときに使える（落ちない）こと • いわゆる「サービスの品質」 •そもそも： • サービスの内容がお客さんの期待を満たすこと 12
- 13. サービスの価値を高める努力 （サイバーエージェントの場合） 1. 膨大な新サービスを続々とリリース • 2015年だけで10サービス以上の提供を開始 2.頻繁な人材流動で開発体制を最適化 • 2011年 スマホシフト、2014年 アメーバ構造改革 3. 明確な撤退ルールで失敗と正しく向き合う • リリースから2年を目処に成果が出なければ撤退 13
- 14. インフラ的なつらさ • 流行れば大量のサーバがすぐに必要になる • チューニングには時間が掛かり限界もある •とにかくサーバ追加で時間を「稼ぐ」（通称：金の弾丸） • 廃れればどんどん縮小させる • 縮小しきれない過剰投資は「損失」でしかない • 新しいプロジェクトには新しい技術を積極導入 • プロジェクトごとに使う技術もバラバラ • サーバの共有はむずかしい 14
- 15.
- 16.
- 17.
- 18. クラウドコンピューティング • 要点 • 共用されたリソースプールから •いつでもどこからでもネットワーク経由で • 必要な分だけをすぐに利用できる 18
- 19. クラウド #とは NIST（米国国立標準技術研究所）による基本特徴の整理 1. オンデマンド・セルフサービス APIでなんでもできる 2. 幅広いネットワークアクセス ネットワーク経由でできる 3. リソースの共用 共用する潤沢なリソースプールがある 4. スピーディな拡張性 すぐに利用可能 5. サービスが 計測可能であること 自らの利用量が適切に計測（されて課金される） 19
- 20. クラウドの分類 運用方法による分類 • パブリッククラウド • 大規模な事業者が運用して数多くの利用者が共有 •AWSとかAzureとかいろいろ • プライベートクラウド • 社内で単独で運用 • YahooとかCyberAgentとか 20
- 21. パブリッククラウド • 大規模な事業者 • 豊富なリソースにもとづく最適化 •膨大な開発能力にもとづく多種多様な機能 • 責任共有モデル • ざっくりOSから下は事業者がセキュリティを担保 • 各種セキュリティガイドラインへの準拠 • むしろベストプラクティスが実装された環境 • OSとその上は利用者がセキュリティを自力で担保 21
- 22. プライベートクラウド • 既存の自前でデータセンタ借りてサーバ置くモデル • OpenStackなどのクラウドコントローラでクラウド化 •基本機能はAmazon等と似たようなことができる • 多種多様な機能は少ない • プライベートでの差別化 • 既にノウハウや購買力を持つ場合 • システム間が密結合（消極的理由） • これらを維持しつつ、クラウドや仮想化のメリットを享受 22
- 23. クラウドのサービス分類 サービス形態による分類 • SaaS • 具体的なアプリケーションとして提供される。 •DropboxとかGmailとか • PaaS • アプリケーションが動く環境が用意される。 • Herokuとか • IaaS • サーバ一式が用意される。いわゆるレンタルサーバに近い。 • ネットワーク機能（FW、LB等）も提供されたりする。 23
- 24. クラウドのサービス分類 サービス形態による分類 • SaaS • 具体的なアプリケーションとして提供される。 •DropboxとかGmailとか • PaaS • アプリケーションが動く環境が用意される。 • Herokuとか • IaaS • サーバ一式が用意される。いわゆるレンタルサーバに近い。 • ネットワーク機能（FW、LB等）も提供されたりする。 24
- 25. クラウド(IaaS)でサーバを確保 • 自由なサーバの追加・削除が可能になる • すぐにサーバが増やせる！ ↔これまでは最大想定分だけのサーバを事前に用意 ↔ 想定を超えるとすぐに対応ができない • 要らないサーバはいつでも捨てられる！ ↔ 資産の耐用年数（5年程度）を使い切れない ↔ 挑戦的なサービスをリリースできない 25
- 26.
- 27. 具体的にイメージしてみよう • サーバはすぐに確保・削除できる ↓ • 作ったサーバに環境構築してすぐ本番投入したい •本番投入中のサーバでもすぐに消したい 27
- 28. 「ペット」から「家畜」へ • これまで：サーバ＝ペット • 1台1台名前を付けて、手間を掛けて育てていく •少しおかしくなっても直して死ぬまで面倒を見る • これから：サーバ＝家畜 • 集団の役割だけを見て、1台ずつの個別の面倒は見ない • おかしくなったら殺す 28
- 29. Discussion クラウド環境のアーキテクチャ • Webシステムのアーキテクチャを考えてみよう • クラウド環境では何が問題になるか •どうすれば解決できるか • ポイント • 作ったサーバに環境構築してすぐ本番投入したい • 本番投入中のサーバでもすぐに消したい 29
- 30.
- 31. Discussion クラウド環境のアーキテクチャ • Webシステムのアーキテクチャを考えてみよう • クラウド環境では何が問題になるか •どうすれば解決できるか • ポイント • 作ったサーバに環境構築してすぐ本番投入したい • 本番投入中のサーバでもすぐに消したい 31
- 32. ポイント1 作ったサーバに環境構築してすぐ本番投入したい • サーバの構築や運用の手間はかわらない • ミドルウェア入れて設定ファイルを変更 •アプリの動作に必要なライブラリも入れる • 最新のアプリケーションをデプロイ（設置） • アプリケーション設定（DB認証情報等）も設置 • アプリケーションのプロセスを起動 32
- 33. ポイント2 本番投入中のサーバでもすぐに消したい • サーバ内に記録されたデータはどうする？ • データベース •セッション情報 • アクセスログ、エラーログ、デバッグログ • システムログ（syslog, イベントログ） • 一時的に手で入れたテスト用設定 33
- 34. クラウド時代の考え方 • サーバの設計方法も合わせていこう！ • 構築や運用が楽になる方法を作る •システム全体のデータの記録方法を見直す ※物理サーバの考えを引っ張るとむしろ高く付くことも 34
- 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. コードベース II.依存関係 III. 設定 IV. バックエンドサービス V. ビルド、リリース、実行 VI. プロセス 38 VII. ポートバインディング VIII. 並行性 IX. 廃棄容易性 X. 開発/本番一致 XI. ログ XII. 管理プロセス
- 39. Twelve-Factor App I. コードベース バージョン管理されている1つのコードベースと 複数のデプロイ •1つのコードベース • アプリケーション全体が一つのレポジトリ • それ以外は、依存ライブラリか参照先の外部システム • 複数のデプロイ • 本番環境、ステージング環境、開発環境 • 全ての変更をきちんと記録・追跡 39
- 40. Twelve-Factor App III. 設定 設定を環境変数に格納する •デプロイごとに異なる設定 • DB接続先とかドメイン名とか • アプリ本体に設定を保存しない • 起動時に動的に設定できるようにする • あたらしい種類のデプロイをすぐ作れるようにする • ソースコードを完全に同一にできる 40
- 41. Twelve-Factor App XI. ログ ログをイベントストリームとして扱う •時系列で継続して吐き出され続ける「ストリーム」 • アプリは吐き出すだけで、自分でファイルとかに保存しない • 開発環境ならコンソールで眺めてみんな大好き目grep • 本番環境ならログ用ストレージに転送 41
- 42. Twelve-Factor App I. コードベース II.依存関係 III. 設定 IV. バックエンドサービス V. ビルド、リリース、実行 VI. プロセス 42 VII. ポートバインディング VIII. 並行性 IX. 廃棄容易性 X. 開発/本番一致 XI. ログ XII. 管理プロセス
- 43. じゃあ、Statefulサーバは？ 「銀の弾丸」は無いが、現実的な選択肢は増えている。 1. スケールアップで対応（金の弾丸） • 「Fusionioは甘え」でもいいじゃないか 2. 分散DB • Cassandra、HBase、MongoDBとかとか 3. すごいストレージサービスを使う • Amazon DynamoDBやGoogle BigQuery 43
- 44. 脱線： 分散DBにおけるCAP定理 44 • どれかが犠牲になる • 可用性 バルスできない •一貫性 バルス書いた筈なのに 読めたり読めなかったり ※結果整合性 • ネットワーク分断耐性 バルス書いたのに サーバが死んで消えた 可用性 一貫性 ネットワーク 分断性
- 45. クラウド時代のサーバ設計 • Statelessサーバ • アプリを動かす •台数でコントロールできる状態を保つ • Statefulサーバ • データを保存 • 気合い入れて頑張る 45
- 46.
- 47.
- 48. 万能じゃない • SSHとかStatefulサーバの脆弱性もある • きちんと脆弱性を評価して優先度を決めよう！ •共通脆弱性評価システム：CVSS v2 https://www.ipa.go.jp/security/vuln/CVSS.html • 脆弱性チェックの自動化ツール：Vuls https://github.com/future-architect/vuls CVSSスコアで危険なものだけ通知できる 48
- 49. CVSS v2の基準 • 基本評価基準(Base Metrics) • 脆弱性そのものの特性 • 機密性、完全性、可用性への影響、 攻撃のしやすさ（ネットワーク経由の攻撃可否など） • 現状評価基準 (Temporal Metrics) • 今どれぐらいやばいか • 環境評価基準 (Environmental Metrics) • 二次被害の度合いとかその他の影響範囲 49
- 50. 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) 50
- 51. クラウドの管理 • コントロールパネル • ブラウザで人がログイン •マウスでクリッククリッククリック…… • つらい • 人間は必ずミスをする • そもそも人の意志決定の余地は少ない 51
- 52. APIによるアクセス • サーバ環境をAPIで操作可能 • APIの認証情報（アクセスキー）を利用 •コントロールパネルとほぼ同じ操作が可能 • APIの利用 • APIを利用するライブラリやCLIコマンド • REST API • 自動処理が可能に！ 52
- 53. APIが万能である故の問題 • APIの認証情報があれば何でもできてしまう • 自動化プログラムとかにカジュアルに組み込みやすい •なにかされたことにすぐに気付きにくい 53
- 54. クラウドの管理 • 適切なアクセス制御 • 本当にその人に必要な作業しか実行させない •最小権限の原則 • 操作内容の監査（記録） • 誰がその作業をしたのかを記録 • あやしい行動をチェックできる 54
- 55. 最小権限の原則 • 情報セキュリティで最も重要な原則 • 必要最小限の権限だけを用意する •例：アクセスキーの権限を最低限にする • 社外のIPアドレスから操作する権限は本当に必要？ • サンパウロでサーバ作成する権限は本当に必要？ • 1時間1400円もするサーバを作成する権限は(同上) 55
- 56. AWS Identity andAccess Management （IAM） • アクセス権限を管理する仕組み • AWSは元々は1アカウント＝1認証情報（email/password) • ユーザやグループを作成して、権限を細かく割り当て可能 • より抽象化した「ロール」への割り当てもできる • アクセス元IPアドレスなども設定可能 56
- 57. AWS CloudTrail • 操作内容を記録する •Amazon S3（ストレージサービス）に保管 • 別のAWSアカウントにも送り込める • 外部の分析サービスとの連携も可能 57
- 58. 前半のまとめ • クラウドコンピューティング • ペットから家畜へ、StatelessサーバとStatefulサーバ •APIの利用 • IDと権限の管理 58
- 59.
- 60.
- 61. クラウドのサービス分類 • いわゆるIaaS • サーバ単位で借りる •いわゆるPaaS • 機能単位で借りる • Heroku、AWS Lambdaのような実行環境 • Amazon RDSやAWS IoTのような具体的な機能 61
- 62.
- 63. PaaSの活用 • 「ありもの」を組み合わせる • 餅は餅屋モデル •「EC2使ったら負け」 • システム自体の変化が強いられる • 一見高く見えることも • これまで見えていなかったコスト・リスクの可視化 • 上手くはまる＝最適化できると画期的なコスト減も 63
- 64. Amazon Web Services(AWS) • 世界で一番大規模なクラウド事業者 • 対抗馬はMicrosoft Azure • シェアはまだ大きな差がある • 機能面では追いつきつつある（部分的に先行） 64
- 65.
- 66. AWSのポイント • 責任共有モデル • OSから上を利用者が責任を持つ （アマゾンは責任を持たない） •OSから下はアマゾンが責任を持つ • 独特な冗長化設計 • リージョンとアベイラビリティゾーン 66
- 67. リージョンとアベイラビリティゾーン • リージョン（Region） • 一つの地域に置かれ、システム的に独立したまとまり •「東京」「オレゴン」「北カリフォルニア」 • アベイラビリティゾーン（AZ） • 1つのリージョン内に複数設置されたまとまり • 一つの故障が複数のAZで併発しないように分離 • 個別のデータセンターを想定 67
- 68.
- 69.
- 70. AWSでの冗長化の基礎 • 「サーバ」という枠がないもの • ElasticLoad Balancer （ロードバランサー） • DynamoDB （NoSQLデータベース） • などなど • これらはAZを意識せずに冗長化されている • これらの活用が運用を楽にする勝利の鍵 70
- 71. サーバインフラのコード化 • 「Infrastructure asCode」 • サーバ構成をコード（具体的にはJSONやRubyベースの DSLなど）で実装し、それをもとにAPIをたたいて展開 71
- 72. Terraform • AWSやAzureの構成をコード化 • コードに合わせて必要なサーバやコンポーネントを作成 •不必要になったら削除 • JSONで書く • 信頼と安定のHashicorp 72
- 73. 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/ 73
- 74. Terraformの設定例 74 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 }
- 75. Infrastructure as Codeの目的 •「プログラミングの手法」をインフラ管理に適用 • Git等によるリビジョン管理、Pull-Requestレビュー • テスト駆動 • 再利用しやすいDSL（ドメイン固有言語）による記述 • Terraformでかなりの部分を実現 • AWS自身のCloudFormationなどもある • サーバ「内部」の管理は……？ 75
- 76. サーバの構成管理 • サーバの環境（アプリケーションの実行環境）を管理 • OSの設定 •ミドルウェアの導入 • ミドルウェアの設定ファイルの設置 • アプリケーションの設置に必要な調整 76
- 77. サーバ構成管理の歴史 1. 職人芸 2. 手順書 3.シェルスクリプト 4. 構成管理ツール 5. アプリケーションコンテナ＋軽量なツール 77
- 78. 構成管理ツール • Puppet、Chef、Ansible • 主な違い •対象サーバのリストの管理方法 • 対象サーバへのソフトウェア導入要否 （≒SSHだけで遠隔操作できるか） • 構成を記述するDSL Puppet=独自DSL、Chef=内部DSL(Ruby)、Ansible＝YAML • 冪等性の担保（差分を計算して適用） 78
- 79.
- 80. アプリケーションコンテナ • アプリケーションの実行環境をパッケージにしたもの • ファイルシステム一式 •OS環境 • 必要なライブラリ・ミドルウェア • アプリケーション本体 • コンテナ起動時に実行するコマンドライン • 外部に公開する(LISTENする)TCPポート番号 • 外部と共有するファイルシステムのパス 80
- 81. Docker • アプリケーションコンテナの実行環境＋α • 仮想化機能の上でアプリケーションを実行 •DockerHubからコンテナイメージを取ってくる • 複数のコンテナを同時に管理する docker-compose • その他様々な管理ツールの集合体 81
- 82. コンテナ時代の構成管理 • ゼロからアプリケーションを動かせば良い • 冪等性を考えたりとかしなくて良くなった •実はそれシェルスクリプトでよくね？ • DB接続先などは、コンテナのイメージとして配るのでは無 く、起動時に設定したい • シェルスクリプト（標準のDockerfile）小さなツール 82
- 83. アプリケーションPaaS（aPaaS） • より汎用な枠組み • アプリケーションの実行環境の準備、運用を、 全て自動化されたaPaaSに「おまかせ」 •Heroku、Amazon Beanstalk、Azure Web Apps • Dockerコンテナを動かせたりもする 83
- 84. サーバレスアーキテクチャ • 最近流行りのキーワード • Question:サーバ「レス」とは？ 84
- 85.
- 86. サーバレスなアプリケーション実行環境 • 「フルマネージドなPaaS」の発展系 • 利用者にとって「サーバ」という管理単位をなくしたい •その筋のプロである「クラウド事業者」が、それぞれの方法 で適切に管理してくれる＝フルマネージド • 以下のような特徴 • 事前に「台数」の確保が不要 • 短時間で起動し、必要なだけ拡張 • 実際の実行時間で課金される
- 87. サーバレスなアプリケーション実行環境 • 基本的には、高度に発達したアプリケーションPaaS • AWSLambdaの例 • 1プロセスが利用する最大メモリ量を指定（例：256MB） • 100ミリ秒単位で、実際に消費した時間を課金 • 呼び出し頻度に応じて、自動的にプロセス起動数を管理 87
- 88. 制約とメリット • アプリケーションのプロセス起動・終了を任せる ⇒ プロセス内にデータを保存することができない 前半の「Stateless」サーバの考え方の徹底 •「Stateless」という制約を受け入れることで、 「フルマネージド」というメリットが得られる 88
- 89.
- 90. 通信形態の大きな変化 • 従来：リクエスト・レスポンスなどの同期型通信 • リクエストを受けたプログラムが、データベースへの読み書 きなど、レスポンスを返すまで全ての処理を担当 •今後：非同期型通信が普及 • スマホアプリやWebSocket等の普及で、ブラウザまで含めて 非同期なシステムを作ることが増えてきた 90
- 91. サーバレスアーキテクチャの例 91 IoTデバイス SORACOM Funnel Kinesis Streams (AWS Lambda) Status Updater 最新ステータス APIGateway Cognito Identity Amazon S3 (AWS Lambda) Manager App 管理者
- 92.
- 93. リアクティブアーキテクチャ リアクティブ宣言：近代的なシステムを実現するための設計原則 1. 即応性（実現したい価値） • システム全体として素早く、かつ安定した応答時間を保つ。 2.耐障害性（非機能要件） • 障害が発生しても、それをコンポーネント内部に影響を隔離することで、システム全体としての即応性を保つ。 3. 弾力性（非機能要件） • 負荷の増減があっても、ボトルネックを排除し、割り当てるリソースを調整することで、即応性を保つ。 4. メッセージ駆動（アーキテクチャ構成要件） • 各コンポーネント間を、非同期なメッセージ配信で疎結合に保つ。
- 94. リアクティブアーキテクチャ • 超ざっくり言うと、 • 小さなプログラムを •メッセージ駆動で • 繋いでいく • という非同期型アーキテクチャが良い、という考え方 94
- 95. サーバレス時代のセキュリティ • これまで • 一つの大きなアプリケーションの「中身」に侵入 •アプリケーションの実装方法の脆弱性 • これから • 小さなアプリケーション⇒実装レベルの脆弱性は減少してほしい… • コンポーネントの利用方法レベルの脆弱性 • ID管理に基づいたコンポーネント単位の認可がより重要に 95
- 96. サーバレスアーキテクチャの本質 • 動かしたいのは「サービス」で「サーバ」ではない • Statelessという制約を受け入れることで、「サーバ」という 単位で管理する必要を無くした •フルマネージドなサービスの活用＝「餅は餅屋」 • サービスの実現のためのベストプラクティスの一つ 96
- 97. 最後に • 特にこの10年のインフラ業界は動きが早いです • クラウドが登場して（まだ）10年間 •前提が変わり、ベストプラクティスが入れ替わる • 個人的には、 ・この10年で物理サーバからクラウド上の仮想サーバに ・今後10年でサーバという枠組みから解放 と予想しています • ツールレベルの盛衰は、一々取り上げるのも切りが無い • 動きが早い＝面白い！ 97
- 98. 最後に • すぐに手を動かそう！ • 無料クーポン、無料枠を活用しよう •大きな機能もちょっとだけなら安くお試しできる！ • とにかくネタと機会を作って情報を発信しよう！ • 情報は活動する人の近くに集まる • ブログ等での情報発信 • 勉強会等での発表 • 同人誌等の制作、頒布 98
- 99. まとめ • クラウド時代のWebシステムについて • サーバ設計、構築、運用技術の基礎 •サービスの無停止とスケーラビリティを実現する設計 • 継続的インテグレーション、高速なリリースサイクル • クラウドのさらなる活用 • Infrastructure as Code • アプリケーションPaaS • サーバレスアーキテクチャ 99