AWS CDP道場を同期と一緒に開催した話

はじめに

こちらの記事は、CA21 Advent Calendar 2020の12日目の記事です！
今回は先日内定者同士のイベントとしてAWS CDP道場in21（会社内で行われたAWS CDP道場の21卒のスピンオフイベント）を開催しましたのでその時に感じたことや勉強になったことを簡単にまとめていきたいと思います！

AWS CDP道場って何？

AWSでシステム設計する上で欠かすことのできないCDP(Cloud Design Pattern)を、実践形式のシナリオに沿って設計して体得するワークショップ形式の勉強会です。

開催した経緯

サイバーエージェントではAWSのソリューションアーキテクトの方々が常駐してくださっており週に２、３日程アーキテクチャ等の相談会が行われています。
そして、その中で業務の時間の中で様々なハンズオンやイベントが社内向けイベントとして開催されています。
それらのイベントには配属部署の上長の方、またはチームの許可が下りれば業務時間の中で自由に参加することができます。（仕事の1つとしてawsの人に色々教えてもらえるのは個人的にかなり嬉しいですw）
過去開催されたものとしては

• Well-Architected フレームワークの講座
• AWS Amplifyハンズオン講座
• AWS GameDay(https://developers.cyberagent.co.jp/blog/archives/26934/)

等々が行われています

そして今回社内イベントとしてAWS CDP道場が行われたのですが、、、

僕自身の業務が忙しく参加が難しい、、、😭
と、なってしまい参加することができませんでした。
しかし参加した2人の同期に聞いたところ
「めちゃめちゃ良かった！」
との声をもらったので、どうせなら内定者同士でawsのアーキテクチャを考える会をやってみようとなり開催が決定しました。

また、その旨をawsの方にお話しさせていただいたところ当日使っていた資料を快くいただくことができたので、
それをもとにイベントを開催しました。

スケジュール

当日のスケジュールとしてはこのようなスケジュールで行いました。
お題を発表してからすぐにアーキテクチャ設計を開始し1時間でアーキテクチャを考え図にまとめなければいけなかったのはとても大変でした。

今回のお題

今回のお題は上記のようなというような要件を満たす
サービスのインフラを考えるというものでした。

用件の機能の多さもさることながら、
チャット流量10万req/s, データ流量10GB/sという処理速度についても求められるようなかなり高度な用件です

僕たちのチームのアーキテクチャ

これらの要件をみてから1時間でチームメンバーと一緒にアーキテクチャ図を考え、最終的に以下のような構成になりました。

要素もかなり多くごちゃごちゃしてしまったので今回はざっくりと６箇所について軽く解説をしていこうと思います。

①メインのアプリケーションサーバ

今回メインのアプリケーションサーバはECSとしました。
理由としてはdockerを用いることでローカル環境とプロダクション環境の環境差異を少なくすることができるということが一番大きな理由です。もう一つの選択肢としてEKS(kubernetes)も選択肢としてありましたが、バージョンアップのスピードについていく大変さ学習コストのたかさなどから今回は外しました

②データベース

今回はuser情報などはAmazon aurora, チャットなどはAmazon DynamoDBを用いて構成することとしました。
アプリケーション内で複数のDBの種類があることは少し運用のめんどくささがある気がしますが、今回の要件としてチャット流量10万req/sというのがあったのでRDBでは処理が追いつかないという懸念があったため今回チャットのDBだけDynamoDBを用いることとしました

③CI/CD

github action, code build, code deployなどを使いCI/CDパイプラインの構築を行っています

④不要データの処理

今回要件としてメッセージの保存期間は1年ということでしたがチャットアプリケーションで１年間たったら完全にデータが削除されてしまうという仕様は問題があると感じたため、DynamoDBのライフサイクルポリシーを使って1年たったチャットデータは削除するのではなくS3 Glacierというs3よりもさらに安くデータを保存できるストレージにためるという構成を取りました

⑤検索機能

検索機能についてはaws batchとlambdaを用いて一定の頻度で新しく作成されたチャットデータをElasticsearchにいれるという構築で対応しました。
検索機能の即時性は減ってしまいますが、大量のデータを常に送り続けるという状態はElasticsearch負荷をかけすぎてしまうと考えたためこのような処理にしました

⑥通知機能

最後の通知機能はSQSで通知データをためてlambdaを用いてポーリングしSNSを用いて通知を飛ばしていくというアーキテクチャとしました。SQSを用いた理由としては通知処理はかなりの高負荷がかかるところであり、処理がどこかで詰まったとしても通知機能全体が死ぬということが内容に設計をしました。

以上が僕たちのチームの発表です。
もちろんこれが一番いいアーキテクチャだとは僕たちも思っていませんし、改めて考えたり他のチームの発表を聞いたりしていく中で

• セキュリティ周りの構成をアーキテクチャ図に落とし込めなかったところ
• バッファストリーミングサービスであるKinesisの使用を考えられなかったこと

などなどまだまだ考えられる点があったと感じました。

まとめ

このような形で他３チームが発表を行いそれぞれのチームの発表に対して質疑応答などをしていきました。
チームによってセキュリティ周りを考えられていたり、メインサーバにEKS(kubernetes)を使っていたりと僕自身とてもたくさんの学びとなる機会となりました。参加者にもアンケートを取らせてもらったのですが総じて高評価となっておりまた機会があれば社員さんの方も巻き込んでまたいろんなイベントを開いていけたらと思います！
それにしても内定者の時からこんな感じでお互いの技術を高めあえる環境にあるのは本当に幸せだなと感じますね！