【AWS re:Invent 2023】GBL212-JA | AWS アーキテクチャの 10 の重要な概念[セッション]

セッション概要

公式ポータルより引用

This lightning talk is delivered in Japanese. AWS has continually released new services and features for our customers’ innovation, yet the key principles of architecture design have not changed. In this talk, explore 10 essential and versatile design principles to help increase your AWS utilization.

(DeepL翻訳)
このライトニングトークは日本語で行われます。AWS はお客様のイノベーションのために新しいサービスや機能をリリースし続けていますが、アーキテクチャ設計の重要な原則は変わっていません。本講演では、AWS の利用率を高めるために不可欠で汎用的な10の設計原則を探ります。

AWS を使用する場合に最低限知っておくべき10の概念について、それぞれ概要を説明するセッションです。
どのような場合でも当てはめることができる設計思想が語られていたので、AWS に限らず他のクラウドでも適用できるような内容になっていました。

また、re:Invent は英語でセッションが行なわれますが、このセッションは日本語で行なわれました。

スケーラビリティを確保する

スケールアップとスケールアウトの考え方があるが、クラウドではスケールアウトを考えるべきである

ただし、キャパシティの上限に達してからスケールアウトするような設計はアンチパターン

キャパシティの限界に達成する前にスケールアウトするようにしておき、それを見越して閾値を設定するのがベストプラクティス

環境を自動化する

今までは故障を検知したら、人手でサーバーに接続してトラブルシュートをしていた
しかし、クラウドを使う上では故障を検知、自動的に新規構築することを考えるべき

使い捨て可能なリソースを使用する

一つ前の環境の自動化にもつながる概念で、オンプレのようにサーバーをペットのように大事に扱うのではなく、クラウド上は家畜のように扱う方がうまくいくという考え方
リソースが故障したら直そうとするのではなく、新しく作成することを前提で考える
そして各リソースにはタグをつけることで、属性を持たせておく

また、この概念はリソースが動的にプロビジョニングされるクラウドの特性が前提にある
クラウドの特性を理解した上で、使い捨て可能なリソースを使用する必要がある

例えば、クラウドではパラメータが動的に変化するので、そのことを前提で設計を考える必要がある

コンポーネントを疎結合にしておく

疎結合とは、コンポーネント間の結びつきが弱く、独立性が高いこと

例えば Web サーバーと DB サーバーを使用した構成であれば、サーバーに設定ファイルを直接書くのではなく、間に LB を挟んでおくなどして疎結合な構成にしておくべき
この構成であれば、各サーバーは LB だけを見ればいい状態になる

疎結合にしておくと障害ポイントが掴みやすいことがメリット
また、データを持つ領域と持たない領域を分けておくべき
なお、上記のような構成では処理のつなぎめを作っておくが疎結合なアーキテクチャにつながっている

疎結合な構成では、データをアプリケーションに持たせず、データストアにデータを外出ししておく

サーバーではなくサービスを中心に設計する

マネージドサービスにはあらかじめ耐障害性や可用性が組み込まれているため、特別な理由がない限りはマネージドサービスを使うことを推奨している

そして、ユースケースに応じたマネージドサービスが AWS では用意されている

適切なデータベースソリューションを選択する

前の概念でもあったように、AWSでは目的ごとにソリューションを選択できる
データベースの選択においても、様々な観点から適切なサービスを選択することができる

単一障害点をなくす

冗長性は「可能であれば」ではなく最初から担保しておく
最初から単一障害点がない構成を設計するべき

コストを最適化する

継続的にコストを見直すことで、コスト効率を上げていくことが重要

リソースのモニタリングだけでなく、コストのモニタリングも継続的に実施する

キャッシュを使用する

キャッシュには主に2種類あり、ひとつは CDN
コンテンツをキャッシュすることで、オリジンに対するリクエストを低減できる
それによって、レイテンシーとコスト両方を低減することができる

また、インメモリデータベースを使用することでオリジンに対するトラフィックを絞ることができ、レスポンス時間の短縮を実現可能

全てのレイヤーでセキュリティを確保する

責任共有モデルを前提として、お客様自身でセキュリティを担保する必要がある
今まで紹介した設計概念を使用して、セキュリティを全てのレイヤーで確保することを推奨

所感

なんとなくで理解している設計概念について、体系的に学び直すことができて有益なセッションでした。
どんどん新しいサービスが出ている今だからこそ、こう言った基本的な概念を重視したいと思いました。

また、re:Invent 期間中は英語を浴び続けているので、日本語の LT は非常に安心感がありました。
なんとなく故郷に帰ってきたような気持ちになりました笑

（登壇されていた SA さんも「箸休めとして参加してください」とおっしゃっていました笑）

re:Invent 期間中はこのような日本語セッションも複数ありますので、参加されるかたは一度探してみることをお勧めします！