クラウド
計算資源をサービスとして借りる形態。
モデル#
| モデル | 借りるもの | 例 |
|---|---|---|
| IaaS | 仮想マシン、ストレージ、ネットワーク | EC2、GCE |
| PaaS | 実行環境 | App Engine、Heroku |
| FaaS | 関数の実行 | [Lambda](/ソフトウェア開発/インフラ/AWS Lambda) |
| SaaS | 完成したアプリ | Gmail |
下ほど自由度が高く、上ほど管理が要らない。
何が変わったか#
| 従来 | クラウド |
|---|---|
| 設備投資(買う) | 運用費(使った分だけ) |
| 調達に数週間 | 数分 |
| ピークに合わせて用意 | 必要なときに増やす |
| 容量の見積もりが必須 | 後から変えられる |
**「間違えても後から直せる」**ことが本質的な変化。 初期の容量設計を誤っても致命傷にならない。
責任共有モデル#
| 事業者の責任 | 利用者の責任 |
|---|---|
| 物理設備、ハイパーバイザ | OS の更新(IaaS の場合) |
| ネットワーク基盤 | アクセス制御の設定 |
| サービス自体の可用性 | データの暗号化、バックアップ |
| アプリケーションの脆弱性 |
「クラウドだから安全」ではない。 公開設定の誤りによる情報漏洩は最も多い事故のひとつ。
費用の落とし穴#
| 項目 | 注意 |
|---|---|
| 下り通信 (egress) | 外向きの転送が高い。閉じ込め効果 |
| 常時起動のインスタンス | 使っていなくてもかかる |
| 監視・ログ | 量が増えると無視できない |
| 使わなくなった資源 | 消し忘れたディスク、IP |
ベンダーロックイン#
マネージドサービスを使うほど便利になるが、 移行が難しくなる。
どこまで固有機能に乗るかは意識的な判断が要る。 標準的な技術(コンテナ、S3 互換 API、PostgreSQL)に寄せると 移行の余地が残る。
参考文献#
- Betsy Beyer et al. (eds.). Site Reliability Engineering. O’Reilly, 2016.(全文公開) https://sre.google/sre-book/table-of-contents/
- Michael Armbrust et al. A view of cloud computing. Communications of the ACM 53(4), 2010. https://doi.org/10.1145/1721654.1721672
- AWS. Shared Responsibility Model. https://aws.amazon.com/compliance/shared-responsibility-model/