エンタープライズクラウド部の山下(祐)です。
先日、社内のメンバーとAWS BuilderCards をプレイしました。
私は、各プレイヤーが作成したアーキテクチャが有効かをジャッジする、レフェリーを仰せつかりました。
その時の様子は、近日中に弊社YouTubeチャンネルで公開されるようですので、是非ご覧ください。
初めてのレフェリーで慣れていないせいかジャッジがややブレてしまい、悪徳レフェリーみたいになってしまいました。。どうか温かい目で見ていただければ幸いです。。
さて、AWS BuilderCardsをプレイすることで、改めて、色々なAWSのアーキテクチャに触れる良い機会となりました。折角ですので、その時に考えたこと・感じたこと・調べたこと等について、つらつらと記載してみたいと思います。
はじめに
AWS BuilderCardsについて
AWS BuilderCardsの概要やルールについては、以下ブログで詳しく紹介されていますので、よろしければご参照ください。
アーキテクチャの構築に使用するカードの一覧
AWS BuilderCardsでアーキテクチャの構築に使用できるカードは以下です。結構ありますね。カード毎に枚数は異なります。（AWSサービス名は、BuilderCardsの表記に従って記載します。）
database
| AWSサービス | カード枚数 |
|---|---|
| Amazon Aurora | 2 |
| Amazon DynamoDB | 4 |
| Amazon ElastiCache | 2 |
| Amazon RDS | 2 |
management & governance
| AWSサービス | カード枚数 |
|---|---|
| Amazon CloudWatch | 3 |
| AWS CloudFormation | 3 |
| AWS CloudTrail | 2 |
| AWS Systems Manager | 2 |
| AWS Well-Architected Tool | 2 |
application integration
| AWSサービス | カード枚数 |
|---|---|
| Amazon API Gateway | 3 |
| Amazon EventBridge | 2 |
| Amazon SNS | 3 |
| Amazon SQS | 3 |
| AWS Step Functions | 2 |
analytics
| AWSサービス | カード枚数 |
|---|---|
| Amazon Athena | 2 |
| Amazon Kinesis Data Firehose | 2 |
| Amazon Kinesis Data Stream（現Amazon Data Firehose） | 2 |
| Amazon OpenSearch Service | 2 |
networking & content delivery
| AWSサービス | カード枚数 |
|---|---|
| Amazon CloudFront | 2 |
| Amazon Route53 | 2 |
| Amazon VPC | 2 |
| Elastic Load Balancing | 2 |
compute
| AWSサービス | カード枚数 |
|---|---|
| Amazon EC2 | 8 |
| Amazon EC2 Autoscaling | 2 |
| Amazon ECS | 2 |
| Amazon EKS | 2 |
| AWS Elastic Beanstalk | 1 |
| AWS Fargate | 2 |
storage
| AWSサービス | カード枚数 |
|---|---|
| Amazon EFS | 2 |
| Amazon S3 | 4 |
その他
| AWSサービス | カード枚数 |
|---|---|
| AWS CDK | 4 |
| AWS Cost Management | 2 |
| AWS IAM | 3 |
| AWS Marketplace | 2 |
お断り
本ブログは、AWS BuilderCardsで高得点を出すためのアーキテクチャを考察するわけではありませんので、予めご了承ください。
各カードの特殊効果は考慮せず、あくまで、BuilderCardsで使えるカードを見ながら、AWSアーキテクチャに思いを馳せるものとなります。
アーキテクチャについて思いを馳せる
さて、ここからは、BuilderCardsに入っているAWSサービスを使ったアーキテクチャについて、思いを馳せてみたいと思います。
SNSはたくさんのサービスと統合されている
下記公式ドキュメントを見ていただければお分かりの通り、Amazon SNSは、非常にたくさんのAWSサービスをイベントソースとすることが可能です。BuilderCardsのほとんどのサービスと連携されているのではないでしょうか。
対象のAWSサービスのステータスが変わったり、何かの閾値を超えた際に、SNSトピックに通知が出来るという仕組みが多いようです。
例えば、Amazon Athenaであれば、予め設定したデータ使用量の制限を超えた際に、通知を出すことが可能です。
また、AWS Cost Management であれば、予め設定した予算に応じて通知を出すことが可能です。
そのため、「アプリケーションが必要なメッセージをやり取りするためのSNSと、AWSサービスの状態通知のためのSNS」という感じで、SNSカードを2枚同時出しすることも簡単ですね。 以下は、AWS公式ブログが紹介しているアーキテクチャに、Lambdaデッドレターキュー用のSNSを追加してみた図です。
バックエンドが必要そうなサービスでも、意外とバックエンド無しで何とかなる
Elastic Load Balancing や API Gateway のようなサービスは、一見すると、バックエンドのサービスが無いと成立しないように感じられます。 ただし、これらのサービスは、固定レスポンスや、モック統合によるレスポンスを返すことが可能です。
Elastic Load Balancing では、特定のリクエストに対して固定レスポンスを返すことで、バックエンドの負荷を軽減することが可能です。
API Gatewayでは、モック統合により、APIリクエストに対して固定レスポンスを返すことが可能です。下記公式ドキュメントで説明されている通り、バックエンドの開発完了を待たずに、APIのテストを行うことが可能です。
もし「Elastic Load Balancing や API Gatewayのカードがあるのに、バックエンドに使えるカードがない！！」となった場合は、「固定レスポンスを返します！」「モック統合機能を使います！」などと言って切り抜けましょう。
Lambdaは複数同時出しがしやすい
Lambdaは処理毎に関数を分けて作成するケースが多いため、複数同時出しがしやすいサービスといえると思います。
例えば、以下公式ドキュメントが紹介しているウェブアプリケーションのサンプルアーキテクチャでは、API URLパスに応じて別々のLambda関数をデプロイしています。
また、Lambdaでは様々な処理を行わせることが可能なので、どのようなAWSサービスとも組み合わせやすい事も強みかと思います。サーバレス構成を作るなら、Lambdaカードは積極的にゲットしておくと良いのではないでしょうか。
世の中にはアーキテクチャのリファレンスが溢れている
今回レフェリーを実施するにあたり、事前に、「〇〇（AWSサービス名）アーキテクチャ」でググってみたのですが、AWS公式や各社エンジニアブログ、個人ブログ等、本当にたくさんのアーキテクチャがヒットし、構成図を見ているだけでも楽しかったです。
そこで、ここでは、AWSが公開している中から、私が独断と偏見で選んだ、ちょっとオシャレな(？)アーキテクチャをご紹介します。
SQSのキューの長さに応じて、AutoScalingをスケールさせる
最初にご紹介するのは、SQSのキューの長さをCloudWatchで取得し、キューの長さに応じて、処理用のEC2をスケールさせる構成です。
AutoScalingというと、CPU使用率などでスケールさせる構成を私は思い浮かべますが、「キューの長さでスケールさせる」というのがちょっとオシャレですね。
Simple File Manager for Amazon EFS
Simple File Manager for Amazon EFS は、専用のWEBページから直接EFSのデータを操作できるようにしたソリューションです。AWSサービスを組み合わせてソリューションが作られており、実装ガイドとCloudFormationテンプレートが公開されています。
EFSというと、EC2からマウントする構成を私は思い浮かべますが、サーバレス構成と組み合わせて、API GatewayとLambdaでアクセスさせるあたりがオシャレですね。
Research and Engineering Studio
最後にご紹介するのは、Research and Engineering Studio という、コンピューティングリソースを払い出すためのWEBサービスを提供するソリューションです。AWSアカウントやAWSの知識が無くてもコンピューティングリソースをセルフサービスで払い出し、利用できるようにしている点が特徴です。
非常に多くのAWSサービスを連携させてソリューションが作られています。こちらもCloudFormationテンプレートが公開されています。アーキテクチャやテンプレートを参考にするだけでも色々と学びがありそうです。ソリューションとしてだけでなく、学習教材としても有用だなんて、オシャレですね。(強引)
ゲームをより楽しむために
さて、ここからは、実際にBuilderCardsをやってみて個人的に感じた、ゲームをより楽しむためのコツのようなものをご紹介します。
アーキテクチャの説明は具体的な方が良い＆アーキテクチャの議論は活発に行った方が盛り上がる
例えば、「API Gateway＋Lambda＋DynamoDB」といった組み合わせだと、パッと見で「まあ一緒に出せるよね」となるのですが、それが具体的にどのようなアーキテクチャを想定しているのか説明せず進めていると、「カードを出して、引いて、切って、、」という作業を淡々と繰り返す感じになってしまいます。今回実際にプレイした時も、序盤はそのような感じで、比較的静かにゲームが進んでいた印象です。
しかし、ゲームも終盤になり、「ここで高得点を出さないと勝てない。そのためには、手持ちのカードを全て使う必要がある。。！！」という状況になると、各プレイヤー、それまでとは打って変わって、強引なアーキテクチャを展開してきました。
そして、そのアーキテクチャを通そうと必死に言い訳説明することで、結果的にアーキテクチャが具体的になり、議論も活発になって、ゲームが非常に盛り上がりました。
（その辺りの様子は、是非、実際の動画を見ていただければ幸いです。）
ですので、アーキテクチャについては具体的に掘り下げ、積極的に議論することをオススメします。
ルール外の部分についても会話すると楽しい
アーキテクチャを議論する際に、ルール外の部分について会話することも楽しいです。
例えば、これは実際にプレイ中にあった会話ですが、VPCカードが無い状態でEC2を出して、「デフォルトVPCにデプロイしているんです！」と言ってみたり、逆に何回もVPCカードを使っていたら「もう上限数に達してない？」「ヤバ、上限緩和申請しなきゃ」とか会話していました。（※）
いずれも、公式のルールで特に既定されているわけではありませんが、実際にAWSを利用する際のあるあるやハマりポイント等を踏まえて会話すると、ゲームがより盛り上がりますので、オススメです。
（※）リージョンあたりのVPCの上限数は、デフォルトでは 5 となっています。この値は上限緩和申請により引き上げることが可能です。
まとめ
以上、AWS BuilderCardsをプレイした感想あれこれでした。
みんなで楽しく遊びながら、AWSを学習できる、非常に優れた知育玩具(？) だと思います。皆様も是非、AWS BuilderCards をプレイして、AWSを楽しく学習しましょう。
非売品なので、そもそも手に入れるのが一苦労ですが。。
山下 祐樹(執筆記事の一覧)
2021年11月中途入社。前職では情シスとして社内ネットワークの更改や運用に携わっていました。 2023 Japan AWS All Certifications Engineers。
