クラウドセキュリティ基礎

クラウドセキュリティ基礎

株式会社WHERE

IoT基盤センターサービスプロデューサー兼 情報システム室インフラエンジニア

仲山昌宏

講師プロフィール

•仲山昌宏

•いわゆるセキュリティエンジニア……ではありません

•秋葉原生まれ大手町育ちの歌って踊れる江戸っ子インフラエンジニア

•株式会社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システムについて

•サーバ設計、構築、運用技術の基礎

• サービスの無停止とスケーラビリティを実現する設計

• 継続的インテグレーション、高速なリリースサイクル

•クラウドのさらなる活用

• Infrastructure as Code

• アプリケーションPaaS

• サーバレスアーキテクチャ

5

サービスの運用とは

• 1時間サービスが止まったときの被害はおいくら？

6

経歴

• 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

8

https://www.cyberagent.co.jp/ir/about/factsheet/

サービスの運用とは

• 1時間サービスが止まったときの被害はおいくら？

• 2016年3Qのゲーム事業売上高：306億円（四半期決算）（2016/04/01～2016/06/30：91日間）

• 1時間あたり1,401万円（1分あたり23万円）

•ピークタイム（稼ぎ時）

•期間限定イベントのラストスパート

•月初（キャリア決済の限度額がクリア）

•年始めのおみくじ代わり

9

サービスの運用とは

•目的：

• ITを使って「お金を稼ぐ」

•手段：

•お客さんにサービスを提供し、その対価を受け取る（直接部門）

•従業員にサービスを提供し、生産性を向上させる（間接部門）

10

サービスの価値

•使いたいときに使える（落ちない）こと

•いわゆる「サービスの品質」

11

サービスの価値

•使いたいときに使える（落ちない）こと

•いわゆる「サービスの品質」

•そもそも：

•サービスの内容がお客さんの期待を満たすこと

12

サービスの価値を高める努力（サイバーエージェントの場合）

1. 膨大な新サービスを続々とリリース

• 2015年だけで10サービス以上の提供を開始

2. 頻繁な人材流動で開発体制を最適化

• 2011年スマホシフト、2014年アメーバ構造改革

3. 明確な撤退ルールで失敗と正しく向き合う

•リリースから2年を目処に成果が出なければ撤退

13

インフラ的なつらさ

•流行れば大量のサーバがすぐに必要になる

•チューニングには時間が掛かり限界もある

•とにかくサーバ追加で時間を「稼ぐ」（通称：金の弾丸）

•廃れればどんどん縮小させる

•縮小しきれない過剰投資は「損失」でしかない

•新しいプロジェクトには新しい技術を積極導入

•プロジェクトごとに使う技術もバラバラ

•サーバの共有はむずかしい14

それクラウドでできるよ

15

クラウドコンピューティング

16

https://www.ipa.go.jp/files/000025366.pdf

クラウドコンピューティング

17

https://www.ipa.go.jp/files/000025366.pdf

クラウドコンピューティング

•要点

•共用されたリソースプールから

•いつでもどこからでもネットワーク経由で

•必要な分だけをすぐに利用できる

18

クラウド #とは

NIST（米国国立標準技術研究所）による基本特徴の整理

1. オンデマンド・セルフサービスAPIでなんでもできる

2. 幅広いネットワークアクセスネットワーク経由でできる

3. リソースの共用共用する潤沢なリソースプールがある

4. スピーディな拡張性すぐに利用可能

5. サービスが計測可能であること自らの利用量が適切に計測（されて課金される）

19

クラウドの分類

運用方法による分類

•パブリッククラウド

•大規模な事業者が運用して数多くの利用者が共有

• AWSとかAzureとかいろいろ

•プライベートクラウド

•社内で単独で運用

• YahooとかCyberAgentとか

20

パブリッククラウド

•大規模な事業者

•豊富なリソースにもとづく最適化

•膨大な開発能力にもとづく多種多様な機能

•責任共有モデル

•ざっくりOSから下は事業者がセキュリティを担保

•各種セキュリティガイドラインへの準拠

•むしろベストプラクティスが実装された環境

• OSとその上は利用者がセキュリティを自力で担保

21

プライベートクラウド

•既存の自前でデータセンタ借りてサーバ置くモデル

• OpenStackなどのクラウドコントローラでクラウド化

•基本機能はAmazon等と似たようなことができる

•多種多様な機能は少ない

•プライベートでの差別化

•既にノウハウや購買力を持つ場合

•システム間が密結合（消極的理由）

•これらを維持しつつ、クラウドや仮想化のメリットを享受

22

クラウドのサービス分類

サービス形態による分類

• SaaS

• 具体的なアプリケーションとして提供される。

• DropboxとかGmailとか

• PaaS

• アプリケーションが動く環境が用意される。

• Herokuとか

• IaaS

• サーバ一式が用意される。いわゆるレンタルサーバに近い。

• ネットワーク機能（FW、LB等）も提供されたりする。23

クラウドのサービス分類

サービス形態による分類

• SaaS

• 具体的なアプリケーションとして提供される。

• DropboxとかGmailとか

• PaaS

• アプリケーションが動く環境が用意される。

• Herokuとか

• IaaS

• サーバ一式が用意される。いわゆるレンタルサーバに近い。

• ネットワーク機能（FW、LB等）も提供されたりする。24

クラウド(IaaS)でサーバを確保

•自由なサーバの追加・削除が可能になる

•すぐにサーバが増やせる！↔ これまでは最大想定分だけのサーバを事前に用意↔ 想定を超えるとすぐに対応ができない

•要らないサーバはいつでも捨てられる！↔ 資産の耐用年数（5年程度）を使い切れない↔ 挑戦的なサービスをリリースできない

25

具体的にイメージしてみよう

•サーバはすぐに確保・削除できる

26

具体的にイメージしてみよう

•サーバはすぐに確保・削除できる

↓

•作ったサーバに環境構築してすぐ本番投入したい

•本番投入中のサーバでもすぐに消したい

27

「ペット」から「家畜」へ

•これまで：サーバ＝ペット

• 1台1台名前を付けて、手間を掛けて育てていく

•少しおかしくなっても直して死ぬまで面倒を見る

•これから：サーバ＝家畜

•集団の役割だけを見て、1台ずつの個別の面倒は見ない

•おかしくなったら殺す

28

Discussionクラウド環境のアーキテクチャ

• Webシステムのアーキテクチャを考えてみよう

•クラウド環境では何が問題になるか

•どうすれば解決できるか

•ポイント

•作ったサーバに環境構築してすぐ本番投入したい

•本番投入中のサーバでもすぐに消したい

29

30

Discussionクラウド環境のアーキテクチャ

• Webシステムのアーキテクチャを考えてみよう

•クラウド環境では何が問題になるか

•どうすれば解決できるか

•ポイント

•作ったサーバに環境構築してすぐ本番投入したい

•本番投入中のサーバでもすぐに消したい

31

ポイント1作ったサーバに環境構築してすぐ本番投入したい

•サーバの構築や運用の手間はかわらない

•ミドルウェア入れて設定ファイルを変更

•アプリの動作に必要なライブラリも入れる

•最新のアプリケーションをデプロイ（設置）

•アプリケーション設定（DB認証情報等）も設置

•アプリケーションのプロセスを起動

32

ポイント2本番投入中のサーバでもすぐに消したい

•サーバ内に記録されたデータはどうする？

•データベース

•セッション情報

•アクセスログ、エラーログ、デバッグログ

•システムログ（syslog, イベントログ）

•一時的に手で入れたテスト用設定

33

クラウド時代の考え方

•サーバの設計方法も合わせていこう！

•構築や運用が楽になる方法を作る

•システム全体のデータの記録方法を見直す

※物理サーバの考えを引っ張るとむしろ高く付くことも

34

「メリハリ」を付けよう

• Statelessサーバ

•アプリケーションを動かすサーバ

•データを中に一切保存せず、コピーすれば動くレベル

•いつでも追加/削除しやすい状態を保つ

• Statefulサーバ

•データベース、ログ

•追加/削除がしづらいので死ぬ気で守る

•スペックアップや分散DBの利用でスケーラビリティ確保

35

Statelessサーバの指針

• Twelve-Factor App

• http://12factor.net/ja/

•（いくつか宗教的な項目もあるものの）今までに提起された最適解の「まとめ」

36

Twelve-Factor App

I. コードベース

II. 依存関係

III. 設定

IV. バックエンドサービス

V. ビルド、リリース、実行

VI. プロセス

37

VII. ポートバインディング

VIII. 並行性

IX. 廃棄容易性

X. 開発/本番一致

XI. ログ

XII. 管理プロセス

Twelve-Factor App

I. コードベース

II. 依存関係

III. 設定

IV. バックエンドサービス

V. ビルド、リリース、実行

VI. プロセス

38

VII. ポートバインディング

VIII. 並行性

IX. 廃棄容易性

X. 開発/本番一致

XI. ログ

XII. 管理プロセス

Twelve-Factor AppI. コードベース

バージョン管理されている1つのコードベースと複数のデプロイ

• 1つのコードベース

• アプリケーション全体が一つのレポジトリ

• それ以外は、依存ライブラリか参照先の外部システム

•複数のデプロイ

• 本番環境、ステージング環境、開発環境

• 全ての変更をきちんと記録・追跡

39

Twelve-Factor AppIII. 設定

設定を環境変数に格納する

•デプロイごとに異なる設定

• DB接続先とかドメイン名とか

•アプリ本体に設定を保存しない

•起動時に動的に設定できるようにする

•あたらしい種類のデプロイをすぐ作れるようにする

•ソースコードを完全に同一にできる

40

Twelve-Factor AppXI. ログ

ログをイベントストリームとして扱う

•時系列で継続して吐き出され続ける「ストリーム」

•アプリは吐き出すだけで、自分でファイルとかに保存しない

•開発環境ならコンソールで眺めてみんな大好き目grep

•本番環境ならログ用ストレージに転送

41

Twelve-Factor App

I. コードベース

II. 依存関係

III. 設定

IV. バックエンドサービス

V. ビルド、リリース、実行

VI. プロセス

42

VII. ポートバインディング

VIII. 並行性

IX. 廃棄容易性

X. 開発/本番一致

XI. ログ

XII. 管理プロセス

じゃあ、Statefulサーバは？

「銀の弾丸」は無いが、現実的な選択肢は増えている。

1. スケールアップで対応（金の弾丸）

•「Fusion ioは甘え」でもいいじゃないか

2. 分散DB

• Cassandra、HBase、MongoDBとかとか

3. すごいストレージサービスを使う

• Amazon DynamoDBやGoogle BigQuery

43

脱線：分散DBにおけるCAP定理

44

•どれかが犠牲になる

•可用性バルスできない

•一貫性バルス書いた筈なのに読めたり読めなかったり※結果整合性

•ネットワーク分断耐性バルス書いたのにサーバが死んで消えた

可用性

一貫性ネットワーク

分断性

クラウド時代のサーバ設計

• Statelessサーバ

•アプリを動かす

•台数でコントロールできる状態を保つ

• Statefulサーバ

•データを保存

•気合い入れて頑張る

45

クラウド時代の脆弱性対応

•アプリケーションの脆弱性が圧倒的に多い

•いかに迅速に動作確認して適用するか

46

Blue-Green Deployment

•もう1セット（Green）作って古い方（Blue）を捨てよう！

47

ｃ

L

B

サーバー

サーバー

サーバー

サーバー

③問題が無ければ古い環境（Blue）を廃棄

①新しいバージョン（Green）の環境を構築

②Greenにアクセス先を切り替え

DB

共通環境

万能じゃない

• SSHとかStatefulサーバの脆弱性もある

•きちんと脆弱性を評価して優先度を決めよう！

•共通脆弱性評価システム：CVSS v2https://www.ipa.go.jp/security/vuln/CVSS.html

•脆弱性チェックの自動化ツール：Vulshttps://github.com/future-architect/vulsCVSSスコアで危険なものだけ通知できる

48

CVSS v2の基準

•基本評価基準 (Base Metrics)

•脆弱性そのものの特性

•機密性、完全性、可用性への影響、攻撃のしやすさ（ネットワーク経由の攻撃可否など）

•現状評価基準 (Temporal Metrics)

•今どれぐらいやばいか

•環境評価基準 (Environmental Metrics)

•二次被害の度合いとかその他の影響範囲49

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

APIによるアクセス

•サーバ環境をAPIで操作可能

• APIの認証情報（アクセスキー）を利用

•コントロールパネルとほぼ同じ操作が可能

• APIの利用

• APIを利用するライブラリやCLIコマンド

• REST API

•自動処理が可能に！

52

APIが万能である故の問題

• APIの認証情報があれば何でもできてしまう

•自動化プログラムとかにカジュアルに組み込みやすい

•なにかされたことにすぐに気付きにくい

53

クラウドの管理

•適切なアクセス制御

•本当にその人に必要な作業しか実行させない

•最小権限の原則

•操作内容の監査（記録）

•誰がその作業をしたのかを記録

•あやしい行動をチェックできる

54

最小権限の原則

•情報セキュリティで最も重要な原則

•必要最小限の権限だけを用意する

•例：アクセスキーの権限を最低限にする

•社外のIPアドレスから操作する権限は本当に必要？

•サンパウロでサーバ作成する権限は本当に必要？

• 1時間1400円もするサーバを作成する権限は(同上)

55

AWS Identity and Access Management （IAM）

•アクセス権限を管理する仕組み

• AWSは元々は1アカウント＝1認証情報（email/password)

•ユーザやグループを作成して、権限を細かく割り当て可能

•より抽象化した「ロール」への割り当てもできる

•アクセス元IPアドレスなども設定可能

56

AWS CloudTrail

•操作内容を記録する

• Amazon S3（ストレージサービス）に保管

•別のAWSアカウントにも送り込める

•外部の分析サービスとの連携も可能

57

前半のまとめ

•クラウドコンピューティング

•ペットから家畜へ、StatelessサーバとStatefulサーバ

• APIの利用

• IDと権限の管理

58

•休憩

59

後半の目的

•前半「クラウドでサーバを借りて上手くやる」

•後半では、より深く「クラウド」を掘り下げます

60

クラウドのサービス分類

•いわゆるIaaS

•サーバ単位で借りる

•いわゆるPaaS

•機能単位で借りる

• Heroku、AWS Lambdaのような実行環境

• Amazon RDSやAWS IoTのような具体的な機能

61

IaaSの利用

•サーバを自前で用意せずクラウドで借りる

•システム全体を大きく帰ることなく、スケールアップ（性能を上げる）スケールアウト（台数を増やす）

のようなメリットを得やすい

62

PaaSの活用

•「ありもの」を組み合わせる

•餅は餅屋モデル

•「EC2使ったら負け」

•システム自体の変化が強いられる

•一見高く見えることも

•これまで見えていなかったコスト・リスクの可視化

•上手くはまる＝最適化できると画期的なコスト減も

63

Amazon Web Services (AWS)

•世界で一番大規模なクラウド事業者

•対抗馬はMicrosoft Azure

•シェアはまだ大きな差がある

•機能面では追いつきつつある（部分的に先行）

64

65

AWSのポイント

•責任共有モデル

• OSから上を利用者が責任を持つ（アマゾンは責任を持たない）

• OSから下はアマゾンが責任を持つ

•独特な冗長化設計

•リージョンとアベイラビリティゾーン

66

リージョンとアベイラビリティゾーン

•リージョン（Region）

•一つの地域に置かれ、システム的に独立したまとまり

•「東京」「オレゴン」「北カリフォルニア」

•アベイラビリティゾーン（AZ）

• 1つのリージョン内に複数設置されたまとまり

•一つの故障が複数のAZで併発しないように分離

•個別のデータセンターを想定

67

AWSにおける冗長化の基本

同じ役割のサーバを、各AZで半々に設置

68

ap-northeast-1a ap-northeast-1c

Web Web

DBDB

ap-northeast-1

SLAでみる冗長化設計

複数のAZにまたがってサーバ置いていないと、落ちても知らないよ？

69

サービス利用者がインスタンスを実行している複数のAvailability Zoneが、

サービス利用者にとって「使用不能」となること

＝

https://aws.amazon.com/jp/ec2/sla/

AWSでの冗長化の基礎

•「サーバ」という枠がないもの

• Elastic Load Balancer（ロードバランサー）

• DynamoDB（NoSQLデータベース）

•などなど

•これらはAZを意識せずに冗長化されている

•これらの活用が運用を楽にする勝利の鍵

70

サーバインフラのコード化

•「Infrastructure as Code」

•サーバ構成をコード（具体的にはJSONやRubyベースのDSLなど）で実装し、それをもとにAPIをたたいて展開

71

Terraform

• AWSやAzureの構成をコード化

•コードに合わせて必要なサーバやコンポーネントを作成

• 不必要になったら削除

• JSONで書く

•信頼と安定のHashicorp

72

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

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

}

Infrastructure as Codeの目的

•「プログラミングの手法」をインフラ管理に適用

• Git等によるリビジョン管理、Pull-Requestレビュー

•テスト駆動

•再利用しやすいDSL（ドメイン固有言語）による記述

• Terraformでかなりの部分を実現

• AWS自身のCloudFormationなどもある

•サーバ「内部」の管理は……？

75

サーバの構成管理

•サーバの環境（アプリケーションの実行環境）を管理

• OSの設定

•ミドルウェアの導入

•ミドルウェアの設定ファイルの設置

•アプリケーションの設置に必要な調整

76

サーバ構成管理の歴史

1. 職人芸

2. 手順書

3. シェルスクリプト

4. 構成管理ツール

5. アプリケーションコンテナ＋軽量なツール

77

構成管理ツール

• Puppet、Chef、Ansible

•主な違い

•対象サーバのリストの管理方法

•対象サーバへのソフトウェア導入要否（≒SSHだけで遠隔操作できるか）

•構成を記述するDSLPuppet=独自DSL、Chef=内部DSL(Ruby)、Ansible＝YAML

•冪等性の担保（差分を計算して適用）

78

アプリケーションコンテナの登場

•対象サーバの上で直接アプリケーションを実行

↓

•仮想化機能を使って、アプリケーションのパッケージ「コンテナ」の中でアプリケーションを実行

79

アプリケーションコンテナ

•アプリケーションの実行環境をパッケージにしたもの

•ファイルシステム一式

• OS環境

• 必要なライブラリ・ミドルウェア

• アプリケーション本体

•コンテナ起動時に実行するコマンドライン

•外部に公開する(LISTENする)TCPポート番号

•外部と共有するファイルシステムのパス

80

Docker

•アプリケーションコンテナの実行環境＋α

•仮想化機能の上でアプリケーションを実行

• DockerHubからコンテナイメージを取ってくる

•複数のコンテナを同時に管理する docker-compose

•その他様々な管理ツールの集合体

81

コンテナ時代の構成管理

•ゼロからアプリケーションを動かせば良い

•冪等性を考えたりとかしなくて良くなった

•実はそれシェルスクリプトでよくね？

• DB接続先などは、コンテナのイメージとして配るのでは無く、起動時に設定したい

•シェルスクリプト（標準のDockerfile）小さなツール

82

アプリケーションPaaS（aPaaS）

•より汎用な枠組み

•アプリケーションの実行環境の準備、運用を、全て自動化されたaPaaSに「おまかせ」

• Heroku、Amazon Beanstalk、Azure Web Apps

• Dockerコンテナを動かせたりもする

83

サーバレスアーキテクチャ

•最近流行りのキーワード

• Question: サーバ「レス」とは？

84

二つのサーバレスアーキテクチャ

•アプリケーション実行環境としてのサーバレス

•システム全体における役割としてのサーバレス

サーバレスなアプリケーション実行環境

•「フルマネージドなPaaS」の発展系

•利用者にとって「サーバ」という管理単位をなくしたい

•その筋のプロである「クラウド事業者」が、それぞれの方法で適切に管理してくれる＝フルマネージド

•以下のような特徴

•事前に「台数」の確保が不要

•短時間で起動し、必要なだけ拡張

•実際の実行時間で課金される

サーバレスなアプリケーション実行環境

•基本的には、高度に発達したアプリケーションPaaS

• AWS Lambdaの例

• 1プロセスが利用する最大メモリ量を指定（例：256MB）

• 100ミリ秒単位で、実際に消費した時間を課金

•呼び出し頻度に応じて、自動的にプロセス起動数を管理

87

制約とメリット

•アプリケーションのプロセス起動・終了を任せる⇒プロセス内にデータを保存することができない前半の「Stateless」サーバの考え方の徹底

•「Stateless」という制約を受け入れることで、「フルマネージド」というメリットが得られる

88

システム全体における役割としてのサーバレス

一つの大きな「アプリケーションサーバ」

↓

クラウドが提供するコンポーネントの有効活用

↓

細かい「マイクロサービス」の組み合わせに分割

通信形態の大きな変化

•従来：リクエスト・レスポンスなどの同期型通信

•リクエストを受けたプログラムが、データベースへの読み書きなど、レスポンスを返すまで全ての処理を担当

•今後：非同期型通信が普及

•スマホアプリやWebSocket等の普及で、ブラウザまで含めて非同期なシステムを作ることが増えてきた

90

サーバレスアーキテクチャの例

91

IoTデバイス

SORACOM

FunnelKinesis

Streams

(AWS Lambda)

Status Updater

最新ステータス

API Gateway

Cognito Identity

Amazon S3

(AWS Lambda)

Manager App

管理者

複雑なパターン

•Amazon S3に動画ファイルをアップロード

⇒それをトリガにしてフォーマット変換を起動

⇒変換が終わったら動画一覧を再生成

⇒生成できたらCDNのキャッシュをクリア

⇒全部終わったら投稿者にメール

•複雑な機能はピタゴラ装置のように作る

92

リアクティブアーキテクチャ

リアクティブ宣言：近代的なシステムを実現するための設計原則

1. 即応性（実現したい価値）

• システム全体として素早く、かつ安定した応答時間を保つ。

2. 耐障害性（非機能要件）

• 障害が発生しても、それをコンポーネント内部に影響を隔離することで、システム全体としての即応性を保つ。

3. 弾力性（非機能要件）

• 負荷の増減があっても、ボトルネックを排除し、割り当てるリソースを調整することで、即応性を保つ。

4. メッセージ駆動（アーキテクチャ構成要件）

• 各コンポーネント間を、非同期なメッセージ配信で疎結合に保つ。

リアクティブアーキテクチャ

•超ざっくり言うと、

•小さなプログラムを

•メッセージ駆動で

•繋いでいく

•という非同期型アーキテクチャが良い、という考え方

94

サーバレス時代のセキュリティ

•これまで

•一つの大きなアプリケーションの「中身」に侵入

•アプリケーションの実装方法の脆弱性

•これから

•小さなアプリケーション⇒実装レベルの脆弱性は減少してほしい…

•コンポーネントの利用方法レベルの脆弱性

• ID管理に基づいたコンポーネント単位の認可がより重要に

95

サーバレスアーキテクチャの本質

•動かしたいのは「サービス」で「サーバ」ではない

• Statelessという制約を受け入れることで、「サーバ」という単位で管理する必要を無くした

•フルマネージドなサービスの活用＝「餅は餅屋」

•サービスの実現のためのベストプラクティスの一つ

96

最後に

•特にこの10年のインフラ業界は動きが早いです

•クラウドが登場して（まだ）10年間

•前提が変わり、ベストプラクティスが入れ替わる

•個人的には、・この10年で物理サーバからクラウド上の仮想サーバに・今後10年でサーバという枠組みから解放と予想しています

•ツールレベルの盛衰は、一々取り上げるのも切りが無い

•動きが早い＝面白い！97

最後に

•すぐに手を動かそう！

•無料クーポン、無料枠を活用しよう

•大きな機能もちょっとだけなら安くお試しできる！

•とにかくネタと機会を作って情報を発信しよう！

•情報は活動する人の近くに集まる

•ブログ等での情報発信

•勉強会等での発表

•同人誌等の制作、頒布

98

まとめ

•クラウド時代のWebシステムについて

•サーバ設計、構築、運用技術の基礎

• サービスの無停止とスケーラビリティを実現する設計

• 継続的インテグレーション、高速なリリースサイクル

•クラウドのさらなる活用

• Infrastructure as Code

• アプリケーションPaaS

• サーバレスアーキテクチャ

99