クラウド用語の説明が読みづらくてつらい

クラウドのＸＸＸって結局なんなの？

クラウドをあらわす「なんとも言えない表現の用語」に悩まされ、
認定試験などの問題文を読んで混乱させられたときに、
公式提供されているドキュメントを読んで頑張るお話です。
この記事では AWS を例に取り上げますが、
他のクラウドサービスであっても似たような感じではないでしょうか。

例：AWS Well-Architected フレームワーク

• オペレーショナルエクセレンス (運用上の優秀性) (Operational Excellence)
• セキュリティ (Security)
• 信頼性 (Reliability)
• パフォーマンス効率 (Performance efficiency)
• コスト最適化 (Cost Optimization)
• 持続可能性 (Sustainability)

さっそく色々な単語が登場してきました。
とりあえず１つめの「運用上の優秀性」を見てみます。

運用上の優秀性

結論から先に書くと、

(AWS WAの)「運用上の優秀性」とは、
ある組織が顧客満足を実現するにあたって、
高品質な結果を常に達成するための継続的な価値提供と改善活動が行える、
という意図を含んだもの であり、
システム実行と運用手順・変更作業の自動化 (CloudFormation とか）、
モニタリング／イベントへの対応 （CloudWatch、EventBridge、SNS とか） といったものが、
アーキテクチャに組み込まれている状態、と解釈できます。

これからの記載は、上記に至るまでの話です。

タイトルの意味を調べる

「運用上」、これはそのまま "システムの運用において" なのでしょう。
つづく「優秀性」という単語がちょっと引っかかります。
微妙に一般的な表現ではない気がするので、「優秀」さ、ということでよいでしょう。
私が気にしすぎなのでしょうが、こういう所で毎回ちょっとずつ引っかかってしまいますね。

それでは「優秀」とはなにか、goo辞書 によれば、

優秀 - ［名・形動］非常にすぐれていること。また、そのさま。

ということです。これはきっと皆さんご存じですね。
よって「システムの運用が非常にすぐれていること」になりますね！
勝ったッ！第3部完！

残念ながらこの状態のままでは、
「このアーキテクチャでは運用上の優秀性が考慮されているか」
みたいな問いに出くわして負てしまいます。

ということで、AWSドキュメント における「運用上の優秀性」を見にいきます。

ドキュメントを読む

Amazon では、運用上の優秀性とは、優れたカスタマーエクスペリエンスを着実に提供しながら、ソフトウェアを正しく構築するために取り組むことであると定義しています。

まだ私の頭では理解が追い付かないので、
もうちょっと読み進めてみます。

運用上の優秀性の目的は、新機能とバグ修正を迅速かつ確実にお客様に提供することです。運用上の優秀性に投資している組織は、新しい機能を構築し、変更を加え、障害に対処しながら、着実に顧客満足を実現しています。その過程で、運用上の優秀性は、デベロッパーが高品質の結果を常に達成するために役立ち、継続的インテグレーションと継続的デリバリー (CI/CD) を促進します。

ここまで読んで、ちょっとヒントになりそうな文が見つかりました。
〆の部分に書かれている、
「デベロッパーが高品質の結果を常に達成するために役立ち、継続的インテグレーションと継続的デリバリー (CI/CD) を促進」
がポイントになりそうな気がします。

少なくとも、 Amazon が定義している「運用上の優秀性」は、
単にシステムが正常運転するように頑張るだけではない、ということが分かってきました。

解釈した用語の意味を確かめる

さきほどの定義をふまえて「運用上の優秀性」における設計原則や定義を読むことで、
意味するところがなんとなく読めてきます。
（以下は私の解釈による意訳がついています）

• 設計原則
  • 運用をコードとして実行する - スクリプト化で人為的なミスを防止している
  • 小規模かつ可逆的な変更を頻繁に行う - 有益な変更の流れを増やす＝ビジネス価値の提供がしやすく、かつ失敗しても簡単に戻せるようになっている
  • 運用手順を頻繁に改善する - 運用のサイクルが停滞しない仕組みがある
  • 障害を予想する - 価値提供の機会を失わないように考えられている
  • 運用上の障害すべてから学ぶ - インシデント、顧客からのフィードバックといった事象を分析して改善する仕組みがある
• 定義
  • 組織 - ビジネス成果の達成に必要な役割分担ができている
  • 準備 - 関係者がワークロードに期待される動作を理解している
  • 運用 - 成果の測定と運用状態のモニタリングをしている
  • 進化 - 自らの運用を分析し、継続的な改善活動を行っている

まとめ

最初に書いた結論部分のとおり、
トータルの目的は「ビジネス価値の提供」になっていて、
その達成に向けて運用全体の仕組みを作り上げる／見直すにあたっての
ベストプラクティスである、ということが良くわかりました。

セキュリティ (安全性)

せっかくなのでもう１つ見てみましょう。
こちらはちょっと読み方が変わります。

足りない言葉を補う

まずセキュリティとありますが、先ほどのように「何の？」が書いてありません。
これは (AWS クラウドの) 「あらゆる」セキュリティの話なんだな、と解釈する必要があります。¹

また、「セキュリティ」に関しては、
暗黙的に以下のような前提がおかれている
ということも認識しておくと、意味が理解しやすくなります。

• 人間は何かしら問題を起こす
• 置いてあるものには何かしら問題が起こる
  • システムは侵入される
  • サービスは妨害される
  • キーやデータは盗まれる
  • カギをかけても開けられることもある(セキュリティホール)
• 使おうとすると何かしら問題が起こる
  • 通信中のデータ（パケット）は盗み見される
  • 権限以上のデータにまでアクセスされる
• etc...

要するにセキュリティ対策を考えるときは「性悪説」に基づきます。
（これらはコンプライアンスやガバナンスを考えるときも同様）

ドキュメントを読む

ということで Well-Architected における、
セキュリティの柱の設計原則も読んでみます。
（以下は私の解釈による意訳がついています）

• 強力なアイデンティティ基盤を実装する
  • 置いてあるものには何でもアクセスされてしまうので、「最小権限の原則」に従って制御する
• トレーサビリティの維持
  • 何が起こったのか把握できるように準備しておく
• すべてのレイヤーでセキュリティを適用する
  • 置いてあるものには(ry
  • 攻撃者は穴があったら入りたいので、隙を与えないようにする
• セキュリティのベストプラクティスを自動化する
  • セキュリティに関するチェックは重要だが、煩雑なので自動化するとよい
• 伝送中および保管中のデータを保護する
  • 置いてあるものには(ry
  • データは暗号化する。キーも見えない場所に置く
• データに人の手を入れない²
  • データを人が直接操作すると失敗しやすいので自動化する
• セキュリティイベントに備える
  • 発生した問題に対処できることも、安全性の概念の範疇にある

用語が含む範囲を確かめる

つづいてセキュリティの柱の定義も、AWS のサービスと絡めて読んでみます。

• セキュリティの基礎
  • 責任共有モデルとガバナンス、アカウント管理の方法（最小権限の原則とか一元管理ができるほうがよいとか）、そのほか安全な運用方法
• ID とアクセス管理
  • IAM や IAM Identity Center の利用
• 検知
  • CloudWatchや、CloudTrail、 Config、VPC フローログ、ホストレベルの各種ログ などの利用・有効化
• インフラストラクチャ保護
  • NACL、セキュリティグループ（Firewall Managerによる一元管理）、WAF、CroudFront、API Gateway の利用
• データ保護
  • KMS、S3-SSE、RDS、EBS の暗号化（とConfig ルールによるインスタンス） の利用
  • Systems Manager Automation やダッシュボード (QuickSight) の利用
  • VPN、Direct Connect、PrivateLink の利用、SSL/TLS の有効化
• インシデント対応
  • GuardDuty, CloudTrail Insights、CloudWatch Anomaly Detection の利用
• アプリケーションのセキュリティ
  • Inspector、Systems Manager Patch Manager、Securty Hub の利用

まとめ

(AWS WAの)「セキュリティ」では、
ユーザーとデベロッパーどちらの立場から見ても、
安全にアプリケーションを開発・利用できるために必要な要素・サービスは積極的に活用して、
AWS クラウドを 360° から保護してあげましょう、という原則と理解できました。
しかし非常に範囲が広く、残念ながらそれぞれ覚えるしかない、という原則でもあります。

最後に

困ったときに公式ドキュメントを読んでみる取っ掛かりになれば、と思います。

また、より効率的に学習するならば、やはり文明の利器も併用すべきでしょう。
「それって結局なんなの？」を知りたいケースのなかで、
それらしい元ネタのドキュメントがある状態において
いまのところ最善手と思われるのは ChatGPT ですよね。

今回のパターンで利用するならば、
Bing チャットを通すのが最もやりやすいと思います。
Microsoft Edge のサイドバーから Bing チャットを呼び出して、
「開いているページを要約して」とお願いするだけです。³

「信頼性の柱」の公式ドキュメントページを開いた状態で、
Bing チャットに要約をお願いしてみたらこんな感じでした。
とても便利な世の中になりましたね。

1. こういった主語がないキーワードは、往々にして広い範囲が取り扱われていることが多い、という経験則みたいなものです。 ↩

2. こちらはアプリケーション設定のようなデータの変更を自動化してミスを減らしましょう、という概念もポイントですが、それだけではありません。
   データは許可された人が必要な分だけ取り出せる状態でなければならない、という意味も含まれています。
   2023年、某通信事業者さんでの大規模な情報漏洩がありましたが、あれはまさにアンチパターンの例でしょう。 ↩

3. Bing チャットの「通知とアプリの設定」から、「任意の Web ページまたは PDF へのアクセスを許可する」を有効化しておく必要があります。
   サイドバーの３点メニュー（その他のオプション）から、この設定へアクセスできます。 ↩