クラウドコンピューティング解説：必須となる11のアーキテクチャコンセプト（4Kマスタークラス）。

この動画の要点

• - アーキテクチャの壁とマスターブループリント
• - 01. 垂直スケーリング vs. 水平スケーリング
• - 02. ロードバランシングアーキテクチャ（L4 vs. L7 & ヘルスチェック）
• - 03. オートスケーリングと弾力性
• - 04. サーバーレス（FaaS & Firecracker MicroVM）

翻訳されたトランスクリプト

オリジナルの英語ナレーションから翻訳されています。利用可能なオーディオとキャプションはYouTubeによって管理されています。

- アーキテクチャの壁とマスターブループリント

0:00 すべてのソフトウェアエンジニアは、いつかクラウドアーキテクチャの壁にぶつかります。 ノートパソコンでアプリケーションを構築し、本番環境にプッシュすると、 実際のユーザーがアクセスした途端、サーバーがクラッシュし、 データベース接続は枯渇し、AWSの請求書は電話番号のようになります。 ほとんどの開発者は、300種類のAWS製品の頭字語を記憶することで クラウドエンジニアリングを解決しようとします。 しかし、実際のクラウドコンピューティングはベンダーカタログを記憶することではなく、 11の基本的なアーキテクチャプリミティブに基づいて構築されています。

0:34 このマスタークラスでは、スケーリングやロードバランシングから、サーバーレス、イベント駆動型デカップリング、 ストレージ階層、クラウドネットワーキングまで、企業全体のブループリントを順を追って説明します。 ストレージ階層、そしてクラウドネットワーキングまで。 これら11のコンセプトをマスターすれば、AWS、GCP、Azureのあらゆるバックエンドを設計できます。 GCP、またはAzure。 これはThe Daily Diffの内部です。

- 01. 垂直スケーリング vs. 水平スケーリング

0:57 コンセプトその1：スケーリング。 アプリケーションのトラフィックが増加した場合、負荷を処理するには根本的に 異なる2つの方法があります。垂直スケーリング、または水平スケーリングです。 垂直スケーリング、つまりスケールアップとは、既存のマシンに より多くのリソースを追加することです。4つのCPUコアを32にアップグレードしたり、 32ギガバイトのRAMを128ギガバイトに交換したりすることです。 128に交換したりすることです。 垂直スケーリングにはアーキテクチャの変更は一切不要です。コードも

1:28 データベースもまったく同じままです。 しかし、それは残酷なハードウェアの限界に達します。 世界中のどの単一のマシンも1万個のCPUコアを持っていません。 そして、最高級のインスタンスは指数関数的な価格プレミアムを伴います。 水平スケーリング、つまりスケールアウトとは、サーバーを小型で コモディティ価格に保ちつつ、ルーターの背後で複数のインスタンスを並行して実行することです。 1つのインスタンスがクラッシュしても、残りのノードがトラフィックを吸収し、 ダウンタイムはゼロです。水平スケーリングの黄金律は

2:01 ステートレス性です。アプリケーションサーバーはユーザーセッション、 アップロードされたファイル、または状態をローカルディスクに保存できません。 状態は外部データベースまたはキャッシュに保存されなければならず、 どのノードでもあらゆるユーザーリクエストを処理できるようにします。

- 02. ロードバランシングアーキテクチャ（L4 vs. L7 & ヘルスチェック）

2:17 コンセプトその2：ロードバランシング。 水平スケーリングは紙の上では素晴らしいですが、すぐに問題を引き起こします。 1万人のユーザーがドメイン名にアクセスした場合、 どの特定のサーバーがトラフィックを受け取るのでしょうか？ ロードバランサーは、パブリックインターネットとプライベートバックエンドクラスターの間に位置する リバースプロキシとして機能します。 受信するTCPまたはHTTP接続を受け入れ、健全なインスタンスに リクエストを分散します。

2:47 ロードバランサーは主に2つのネットワーク層で動作します。 Layer 4 ネットワークロードバランサーはトランスポート層で動作し、 IPアドレスとポートに基づいて生TCPおよびUDPパケットをルーティングし、 マイクロ秒のレイテンシで毎秒数百万のリクエストを処理します。 Layer 7 アプリケーションロードバランサーはHTTPプロトコル自体を 検査します。URLパス、リクエストヘッダー、Cookie、HTTPメソッドを読み取ります。 これにより、パスベースのルーティングが可能になります。/apiリクエストを バックエンドクラスターに、/staticリクエストをオブジェクトストアに送信します。

3:25 重要なことに、ロードバランサーはアクティブなヘルスチェックを実行します。 数秒ごとに、バランサーはすべてのインスタンスのヘルスエンドポイントにpingを送信します。 インスタンスが3回連続で500エラーをスローしたり、応答しなかったりした場合、 自動的にプールから除外され、リクエストは一切ドロップされません。 リクエストは一切ドロップされません。

- 03. オートスケーリングと弾力性

3:45 コンセプトその3：オートスケーリング。 ウェブアプリが午前3時に2台のサーバーを必要とし、昼間のローンチ時には20台のサーバーを 必要とする場合、クラウドコンソールで手動でボタンをクリックするのは、ダウンタイムと破産への 確実な道です。 オートスケーリングは、水平サーバープールに動的な弾力性をもたらします。 オートスケーリンググループは、平均CPU使用率、ネットワークI/O、キューのバックログ深度などの パフォーマンスメトリクスを監視します。 平均CPUが定義されたしきい値（例えば、3分間連続で70%）を超えると、

4:19 オートスケーラーは自動的に新しい仮想マシンを起動し、ロードバランサーに登録し、 ロードバランサーに登録し、 トラフィックのルーティングを開始します。 同様に重要なのがスケールインです。トラフィックが減少すると、 オートスケーラーは過剰なインスタンスを終了し、アイドル状態のコンピューティング料金を 支払わないようにします。サーバーが無限のスラッシングループで急速に作成および破棄される フラッピングを防ぐために、クラウドアーキテクトはクールダウン期間を構成します。 クールダウン期間を構成します。コンセプトその4：サーバーレス。

- 04. サーバーレス（FaaS & Firecracker MicroVM）

4:53 長年にわたり、マーケティングチームはサーバーレスを空中で実行される魔法のコードとして 宣伝してきました。 実際には、サーバーレスは依然としてサーバーを使用しますが、コードが実行されていないときは それらを所有、パッチ適用、支払う必要はありません。 AWS LambdaやGoogle Cloud FunctionsのようなFunction-as-a-Serviceでは、 スタンドアロンのハンドラ関数を記述します。 HTTPリクエスト、S3ファイルアップロード、またはデータベースの変更が 発生すると、クラウドラ環境は5ミリ秒未満で

5:23 Firecrackerのような一時的なマイクロ仮想マシンを起動します。 コードが実行され、応答を返し、シャットダウンします。 3ヶ月間誰もウェブサイトを訪問しなかった場合、コンピューティング料金は正確に 0ドル0セントです。 同時に100万人のユーザーがアクセスした場合、プロバイダーは100万個の 同時実行マイクロVMを起動します。エンジニアリング上のトレードオフは現実的です。 新しいランタイムを起動する際のコールドスタートレイテンシ、Lambdaでの厳格な15分間の実行制限、 そして厳格なステートレス性。

5:55 サーバーレスはイベントパイプラインや散発的なAPIには最適ですが、 永続的なWebSocketや数時間のトレーニング実行には不向きです。

- 05. イベント駆動型アーキテクチャ（EDAとデカップリング）

6:05 コンセプトその5：イベント駆動型アーキテクチャ、またはEDA。 従来のアーキテクチャでは、サービスは同期的に通信します。 チェックアウトサービスが決済を呼び出し、決済が在庫を呼び出し、 在庫が不正を呼び出し、不正がメールを呼び出します。 これにより、同期的な破滅の連鎖が生まれます。 サードパーティのメールプロバイダーがネットワークの問題で10秒間応答しなかった場合、 顧客のチェックアウトリクエスト全体がエラーでタイムアウトします。 イベント駆動型アーキテクチャでは、サービスは完全に分離されています。

6:37 顧客が購入をクリックしても、チェックアウトサービスはダウンストリームのサービスを呼び出しません。 代わりに、OrderPlacedというイベントをAmazon EventBridgeのような中央のイベントバス、 またはSNSトピックに公開するだけです。 チェックアウトは50ミリ秒で完了します。 決済、在庫引き落とし、メールレシートのためのダウンストリームワーカーは、 それぞれ独自の専用SQSキューからメッセージを独立して取得します。 メールサービスが1時間停止しても、メッセージはキューに安全にバッファリングされ、 注文が1つも失われることはありません。

- 06. コンテナオーケストレーション（Docker & Kubernetes）

7:13 コンセプトその6：コンテナオーケストレーション。 Dockerはパッケージングを解決しました。アプリケーションコード、 システムライブラリ、設定、ランタイムを不変の イメージにラップし、MacBookとクラウドでまったく同じように実行されます。 しかし、コンテナのパッケージングは簡単です。 50台の物理仮想マシンで500個のコンテナを実行するとなると、 エンジニアリングは破綻します。 だからこそ、KubernetesやAWS ECSのようなコンテナオーケストレーターが

7:41 存在します。オーケストレーターはコントロールプレーン（APIサーバー、 etcdステートストア、インテリジェントなスケジューラー）を提供します。 望ましい状態を宣言します。例えば、「認証サービスのレプリカを10個、 それぞれ2ギガバイトのRAMで実行したい」とします。 スケジューラーはクラスターを検査し、空きメモリのあるノードにポッドを配置し、 内部ネットワーキングを構成し、現実の状態を継続的に調整します。 ノードがハードウェア障害を起こした場合、Kubernetesはその損失を検出し、 すべての移動したポッドを健全なノードに即座に再スケジュールします。

- 07. 4つのクラウドストレージの柱（S3、EBS、DB、Redis）

8:16 健全なノードに即座に再スケジュールします。コンセプトその7：クラウドストレージの階層。 初心者はしばしばクラウドストレージをファイルをダンプする単一のバケットとして 扱います。本番アーキテクチャでは、ストレージはアクセスパターンとレイテンシに基づいて 4つの異なる柱に分けられます。 1つ目はAmazon S3やGoogle Cloud Storageのようなオブジェクトストレージです。 簡単なPUTおよびGET呼び出しを使用してHTTP REST API経由でファイルにアクセスします。 簡単なPUTとGETの呼び出しを使用します。 1ギガバイトあたり月額2セントで無限の水平容量を提供し、

8:49 ビデオ、ユーザーアップロード、ログ、バックアップに最適です。 2つ目はAmazon EBSのようなブロックストレージです。 これらは高速相互接続経由で特定の仮想マシンに直接マウントされる 仮想ハードドライブです。 これらはext4のような標準的なファイルシステムにフォーマットされ、 データベースエンジンが必要とする高速なランダム読み取りおよび書き込みアクセスを サポートします。3つ目はマネージドデータベースです。RDS上のPostgreSQLのようなリレーショナルエンジンは ACIDトランザクションと複雑な結合を提供し、DynamoDBのようなNoSQLエンジンは

9:21 大規模なスケールで一桁ミリ秒のレイテンシを提供します。 大規模なスケールで一桁ミリ秒のレイテンシを提供します。 そして4つ目はRedisのようなインメモリキャッシュです。 RAMからのデータ読み取りはミリ秒ではなくマイクロ秒でかかります。 キャッシュはデータベースの前に位置し、繰り返される読み取りトラフィックからデータベースを保護し、 揮発性のユーザーセッショントークンを管理します。

- 08. 高可用性とナイン（マルチAZフェイルオーバー）

9:44 コンセプトその8：高可用性、またはHA。 可用性は1つの質問に答えます。アプリケーションが稼働し、ユーザーから到達可能な時間の 割合はどのくらいですか？ エンタープライズ契約では、可用性はナインで測定されます。 2ナイン、つまり99%の可用性は、毎年3日半以上のダウンタイムを許容します。 毎年3日半以上のダウンタイムを許容します。 4ナインは許容ダウンタイムを52分に短縮し、 5ナインは年間合計ダウンタイムをわずか5分に抑えます。

10:15 高可用性を実現するには、障害ドメイン全体の単一障害点を排除する必要があります。 障害ドメイン全体の単一障害点を排除する必要があります。 クラウドでは、これは複数のアベイラビリティゾーンにデプロイすることを意味します。 アベイラビリティゾーンは単一のラックではなく、独立した電力と冷却を備えた 数マイル離れた1つ以上の異なる物理データセンターです。 ゾーンAとゾーンBで同期データベースレプリケーションを使用してアクティブインスタンスを実行することで、 雷や光ファイバーの切断によって物理設備全体がダウンした場合でも、 自動フェイルオーバーが行われます。

10:50 30秒以内に人間の介入なしで。

- 09. 耐久性 vs. 可用性（11ナインが稼働時間ではない理由）

10:53 概念その9：耐久性と可用性。 これは、クラウドアーキテクチャの面接で最もよくある概念的な落とし穴です。 エンジニアはこれらの言葉を頻繁に同じ意味で使いますが、 それらは全く異なる特性を測定しています。 可用性は稼働時間を測定します。今この瞬間にAPIを呼び出してデータを読み書きできますか？ データは今この瞬間に読み書きできますか？ 耐久性は保存を測定します。私のデータは10年間、永続的なビット腐敗、破損、または破壊なしに存続しますか？ ビット腐敗、破損、または破壊なしに10年間存続しますか？

11:24 Amazon S3 Standardを見てみましょう。 そのサービスレベルアグリーメントは99.9%の可用性を提供し、 これにより、毎月約43分間のダウンタイムが許容され、 その間にAPIリクエストが500エラーを返す可能性があります。 しかし、S3は11のナインの耐久性を約束します。つまり99.999999999%です。 99.999999999% 99.999999999% S3に1000万個のファイルを保存した場合、統計的には1万年に1個のファイルを失うことが予想されます。

11:56 平均して1万年に1つのファイルを失うことが予想されます。 S3は、オブジェクトをイレージャーコーディングし、少なくとも3つの地理的に分離されたデータ施設にチャンクを複製することでこれを実現します。 少なくとも3つの地理的に分離されたデータ施設にチャンクを複製することでこれを実現します。 大規模な地域ネットワーク障害が発生した場合、S3は一時的に利用できなくなる可能性がありますが、 データが破壊されることはありません。

- 10. Infrastructure as Code（Terraform vs. コンソールドリフト）

12:14 概念その10：Infrastructure as Code、略してIaC。 クラウドコンピューティングの初期には、エンジニアはAWSのウェブ管理コンソールにログインし、手動でクリックして仮想マシンを作成したり、 仮想マシンを作成したり、サブネットを設定したり、セキュリティグループをアタッチしたりしていました。 サブネットを設定したり、セキュリティグループをアタッチしたりしていました。 業界ではこれをClickOpsと呼び、本番環境では絶対的な惨事です。 手動のコンソール変更には監査証跡がなく、ロールバックメカニズムもなく、 ステージング環境と本番環境の間で設定のずれが避けられません。Terraform、 本番環境の間で設定のずれが避けられません。

12:48 OpenTofu、Pulumi、またはAWS CDKのようなInfrastructure as Codeツールを使用すると、 OpenTofu、Pulumi、またはAWS CDKのようなInfrastructure as Codeツールを使用すると、 Gitに保存された宣言型の構成ファイルでクラウドアーキテクチャ全体を定義できます。 開いているポートやデータベースレプリカへのすべての変更は、プルリクエストとピアレビューを経由します。 プルリクエストとピアレビューを経由します。 terraform planを実行すると、何かが変更される前に正確なAPIの差分がプレビューされ、 本番スタックの同一のレプリカを起動するのに4週間ではなく4分かかります。 本番スタックの同一のレプリカを起動するのに4週間ではなく4分かかります。

- 11. クラウドネットワーキング（VPC、サブネット、NAT、セキュリティグループ）

13:20 概念その11：クラウドネットワーキングと仮想プライベートクラウド。 サーバーをクラウドにデプロイしても、生のパブリックインターネットに露出したままになることはありません。 それらはVPCと呼ばれるソフトウェア定義の隔離された境界内に存在します。 VPCと呼ばれるソフトウェア定義の隔離された境界内に存在します。 VPC内では、10.0.0.0/16のようなプライベートIPアドレス空間を割り当て、 それをパブリックサブネットとプライベートサブネットに分割します。 それをパブリックサブネットとプライベートサブネットに分割します。 パブリックサブネットには、インターネットゲートウェイへの直接ルートがあります。

13:51 アプリケーションロードバランサーやNATゲートウェイなど、パブリックに面したアセットを保持します。 パブリックIPアドレスを持つネットワークの唯一の部分です。 アプリケーションサーバーと本番データベースは、パブリックIPを持たず、インターネットからの受信ルートがゼロのプライベートサブネットに厳密に存在します。 インターネットからの受信ルートがゼロのプライベートサブネットに厳密に存在します。 バックエンドサーバーがセキュリティアップデートをダウンロードする必要がある場合、 それらの送信トラフィックは、パブリックサブネットのNATゲートウェイを経由します。 すべてのインスタンスを囲んでいるのはセキュリティグループです。これは、最小特権の原則を強制するステートフルな仮想ファイアウォールです。 最小特権の原則を強制するステートフルな仮想ファイアウォールです。

- 12. 完全なエンタープライズブループリントと評価

14:28 データベースセキュリティグループは、ポート5432への接続をアプリケーションサーバーのセキュリティグループからのみ厳密に受け入れ、 5432への接続をアプリケーションサーバーのセキュリティグループからのみ厳密に受け入れ、 外部からの侵入を数学的に不可能にします。 全体像を見ると、これら11のプリミティブが1つのまとまったシステムに接続されます。 DNSはパブリックサブネットのロードバランサーにルーティングされ、 オートスケーリンググループは複数のアベイラビリティーゾーンにわたるトラフィックの急増を処理し、 イベントバスはバックエンドワーカーをデカップリングし、スタック全体が Infrastructure as Codeを使用してGitからデプロイされます。

15:02 今日のマスタークラスの評決：SHIP IT。 何百ものクラウドマーケティングの頭字語を覚えるのはやめましょう。 これら11のアーキテクチャパターンを習得し、ステートをデカップリングし、 失敗しないシステムを構築しましょう。 初めて構築を始めたときに最も頭を悩ませたクラウドの概念をコメントで教えてください。 構築を始めたときに最も頭を悩ませたクラウドの概念をコメントで教えてください。 完全なアーキテクチャチートシートを入手するには、 thedailydiff.devのニュースレターを購読してください。

15:28 リンクは下にあります。今日はこれで終わりです。 AxrisiのNikoです。 責任を持ってマージしてください。

情報源

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io