初めに

近日中に地元でJAWS-UGが行われるため、名刺代わりにこの記事を書くことにしました。

目次

1.自己紹介
 2.SAAの勉強をやるべき３つの理由
 3.AWSサービスを知ることができる
 4.AWSサービスを使用してベストプラクティスを知ることができる
 5.例１：負荷分散のためのオートスケーリング
 6.例２：データ分析基盤構築
 7.自慢できる
 8.みんなもAWS-SSAを受けてみよう！

1. 自己紹介

初めまして！やさしい緑です！IT業界へ入り4年目になります！
・1年目～３年目ごろ：SESや受託開発案件などベンダー側で開発者として活動
　JavaScript（TypeScript）、Python（Pandas）でWebサービス開発など。
・４年目：小売業で社内ベンダーとして活動中
　Kintone、C#で業務ツールの設計、開発など。

また、IT系の資格について勉強中で
・kintone CERTIFIED　アソシエイト
・応用情報技術者試験
を取得のため勉強中です。

また、今年の春ごろにAWS Certified Solutions Architect - Associate(以下SAA)を合格しました！

今回はSAA取得の合格のためにしたこと...の記事はたくさんあるため、SSAを取得すべき理由を挙げていきたいと思います。

2. SAAを取得するべき３つの理由

理由としては以下の３つがあります。
・AWSサービスを知ることができる
・AWSサービスを使用してシステム課題への解決策を提示することができる
・自慢できる

3. AWSサービスを知ることができる

AWSサービスの種類は膨大な上、サービスの中にサービスがある...（EC2の中にEFSetc...）という場合もあり、準備なしで登録すると、何使えばいいの？、どういう風に作ればいいの？となるかもしれません。

画像：Amazon Web Services入門 (AWSの基礎) @nekoharuyuki様　から引用

SSAを学ぶことにより、スパゲッティのような煩雑なサービス構成を解きほぐすことができます。

4. AWSサービスを使用してシステム課題への解決策を提示することができる

ただし、AWSのサービスを知っているからとして、実際に設計できるかどうか？という話になると別問題です。
・課題を解決するためには、どのような設計がベストなのか？
・既存のAWSサービスの要求が高くなった場合、どのように改修すべきか？
・既存のAWSサービスのコストダウンはどのようにすべきか？
などなど、設計に関して様々な課題があると思います。SSAを学ぶとそれらの課題に対して、ベストプラクティスを提示できるようになります。

画像：AWS well Architected Framework Review　から引用。AWSのWell Archtectedを表したもの。AWS設計の重要な概念ですが、今回の説明は省略します。

次に例としてこのような課題に対して、SSAを学ぶとこのような解決策が提示できるよ、ということをお伝えいたします。

5.例１：負荷分散のためのオートスケーリング

あなたはとあるベンチャー企業に勤めています。その企業は、ユーザー投稿型レシピアプリ（クック〇ットのようなサービス）を提供しています。ある日経営層から、ユーザー投稿を増やすために、以下のキャンペーンを行うと伝えられました。

期間中に10本レシピを投稿したら3か月間有料サービスが無料に！また、懸賞品（抽選）もあり！

というキャンペーンです。期間は1か月間ありますがその間は、以下のことが予想されます。

レシピ投稿者数の増加
レシピ閲覧する人の急増

今のシステム構成は以下の通りです。

レシピ投稿システムはApiGateWayを通してLambdaで行う
Lambdaで投稿された記事はAuroraDBへ挿入される
フロントエンドはEC2でReactを使っている

フロントエンドについてはFargete使えよ、という突っ込みがあると思いますが...あくまで例ですのでご了承を。

今回のキャンペーンは、投稿者数、アクセス数が予想できないので以下の懸念点があります。

レシピ投稿の増加で、Lambdaの急激なアクセスが起こり、実行数のスロットリングエラーが起こる可能性がある
サイトアクセス数増加により、EC2サーバーダウンが起こる恐れがある
サイトアクセス数増加により、データベースも読み取りが遅くなる恐れがある

そこで、設計を変えようという話になりました。では、どのように改修しましょうか？

まずはレシピ投稿についての改修を考えます。Lambdaを見てみるとどうやら、スケーリングはデフォルトのまま使用されているようです。その場合は、Provisioned Concurrencyを使用していきましょう。今までの投稿数を分析してProvisioned Concurrencyを設定していきます。そうすることで、急激なアクセスによるスロットリングが起こる可能性が低くなります。

では、アクセス数はどうでしょうか？その場合はロードバランサーを使用してEC2のオートスケーリングを行い負荷分散を行いましょう。今までのCPU使用率などを分析して負荷分散の設定を行います。

また、リソースがあれば、コンテナ管理が行えるFargeteに入れ替えるのもありです。

最後に、Auroraについてもレプリカを使用して読み取りの負荷分散をしましょう。こちらもAuto Scalingができるので、平均接続数などから分析してリードレプリカを設定しましょう。

その他、細かい設定もありますが、このような形で対応できると思われます。水平スケーリングはAWSを使う大きなメリットですので、それらを念頭に設計できると便利ですね。

ではもう一つ行きましょうか。

6.例２：データ分析基盤構築

あなたは、年間売上高50億円で10店舗ほどのスーパーマーケットの社内SEです。
以下のサービスを作りたいよと経営層からの要望がありました。

どの部門、どの商品が売れているのか？また、店舗ごとの、どの商品が売れているのか？知りたいため、それらのデータの見える化をしたい。

そこで、あなたはストコンデータを使用して、データ基盤システムを構築、BIツールでダッシュボード化しようと考えました。

さて、ここまでの条件で、どのようなサービスを構築しましょうか？以下の構築を考えてみます。

EC2を使用してストコンからCSVデータを吸い上げてS3に置く
S3に置いたデータをGlueでデータクレンジングを行い、再度S3へ置く
データクレンジング済みデータを、RedShiftへ読み込ませる
RedShift（Postgres）のマテリアライズドビューにBIツールと連動させる

という構成が考えられます。

ただ、待ってください。この構成は、処理内容に対してオーバースペックな構成になっていませんでしょうか？以下の構成も考えましょう。

EC2を使用してストコンからデータを吸い上げてS3に置く
S3に置いたデータをLambdaでデータクレンジングを行い、再度S3へ置く
データクレンジング済みデータをLambdaでDynamoDBへ挿入する
DynamoDBとBIツールを連動させる

今回は、データクレンジング部分の処理と、データロードを行う先のサービスを変えました。
GlueとRedShiftは高性能ですが、その分コストが嵩みますので代替としてLambdaとDynamoDBに変えています。
もし、データクレンジングがLambdaの実行時間内で済むならば、そちらに変えたほうがいいでしょう。DynamoDBに関しても、処理性能により費用の調整ができますのでDynamoDBで十分ならばそちらでよいかと思われます。

Glueジョブをデフォルトで設定すると月当たり18万円...高い...

RedShiftは一番安いインスタンスで229USDです。

また、リアルタイムのデータを見たい！という~~無茶ぶり~~要求に対しては以下の構成も考えられます

ストコンからのストリームデータをKinesis Streamで吸い上げる
ストリームデータをLamdaでデータクレンジングしてRedshiftへ挿入する
RedShift（Postgres）のマテリアライズドビューとBIツールと連動させる

...まぁこの構成はIot分析ならよく見ますが、BIツールの構成では見たことありませんし、コストが無茶苦茶かかるんですが...こういうことも可能です。

このように、様々な要求、条件に対してのベストプラクティスを提示することができます。

7. 自慢できる

はい、これも大切ですね。Webシステムに携わっている人の9割はAWSのことを知っています（多分）。なので自慢になると思いますよ。あと、上記のことが話せて、設計出来たら「俺こんなことができるんだ！」という自己肯定感上がると思います。

8.みんなもSSAを受けてみよう！

いかがだったでしょうか？AWSに携わる人ならばSSAを取得したほうが良いよね、ということが伝われば幸いです。