明けましておめでとうございます。
Beaver’s Hive正月アドベントカレンダー企画第四弾です。

今回はちょっと毛色を変えてAWSの構成を設計する際に気をつけていることを紹介します。

AWSではAWS Well-Architected フレームワークというベストプラクティスが定義されており、基本的にこれに従って設計を行うことが好ましいとされています。
ですがリンクの内容を見ていただければわかるように、内容が非常に多いです。
これをすべて把握、理解して設計に反映するのは結構大変だったりします。

そこで、AWSのビルディングブロックを考慮することで、ある程度Well-Archに対応できることを紹介します。

ビルディングブロックとは

ここでいうブロックとはレゴブロックのようなおもちゃのブロックを想像してもらうと良いです。
AWSでは複数のサービスが提供されており、これらをブロックのように組み合わせることで1つのシステムを組み上げる考え方をビルディングブロックといいます。
特にサーバレスやマイクロサービスなんかと相性のいい概念です。

例えば、アプリケーションをAmazon ECSで実行する。共通のストレージ領域としてAmazon S3を利用する。ストレージへのファイルの出力にAmazon Data Firehoseを利用する。といったように個々のサービスに役割を分担することができます。

メリット

ビルディングブロックを駆使して複数のサービスを利用することのメリットを以下に挙げます。

まず、機能を独自に開発することなくサービスをSaaS的に利用出来ます。
AWSから提供される機能に対してAPIリクエストを行うだけでシステムに組み込むことができるので開発工数を格段に縮小することが出来ます。サービスによってはセキュリティ等の認証を受けていたり、サーバレス系のサービスではインフラの管理が不要であったり耐障害性が高かったりと非機能の部分でも信頼出来ます。

次に、システムを疎結合に出来ます。個々の機能を個別のサービスに持たせることで機能間が疎結合になり、拡張性が容易になります。
特にAWSのサービスは拡張性が高く、負荷に対するプロビジョニングが要らないサービスが多いため、拡張方法を考慮しなくてよいケースが多いことも利点です。

とはいえ、いくつものサービスを使ってコスト的にどうなの？やりたいことに対して構成が過剰じゃない？と思うケースもあると思います。
サーバレス系のサービスであれば利用した回数やデータの量に応じた課金体系になるので意外とお金がかからずに利用できたりします。かつ利用頻度が増えた場合にもそのままの構成で利用し続けられるという点でも魅力的です。
特にAWS CDKのようなIaCツールで構成管理をしておくことで拡張も縮小も簡単にできるので必要に応じた構成を模索するのも良いかと思います。

まとめ

ビルディングブロックを意識してAWSの設計をしてみてはいかがでしょう。

この企画は明日以降も続きますので楽しみにお待ちいただけると嬉しいです。ではでは✋️