RAKSUL TechBlog

ラクスルグループのエンジニアが技術トピックを発信するブログです

新卒メンバーでAWS研修に参加しました!

こんにちは。21卒新卒エンジニアの山中です。今回は、6月1日〜3日に、新卒メンバー5人で、アマゾンウェブサービスジャパン株式会社様(以下 AWS Japan 様)主催の「AWS Jumpstart for NewGrads」という新卒向け研修に参加してきたので、そのレポートをしたいと思います。

AWS Jumpstart for NewGradsとは?

AWS Jumpstart for NewGrads とは、新卒エンジニア向けに AWS Japan 様が開催している研修イベントです。3日間にわたり、AWS のソリューションアーキテクト(以下SA)の方々と一緒に AWS について学ぶ研修です。今年に関しては、全日程 Amazon Chime や Slack を用いたオンライン開始となっていました。

おおよその研究内容は以下の通りでした。

  • AWS を用いた設計のベストプラクティスに関する講義(2時間)
  • ECS の入門ハンズオン(4時間)
  • Amplify の入門ハンズオン(3時間)
  • 架空のサービスを想定した AWS アーキテクチャ設計のグループワーク課題(10時間)
  • SA の方との座談会
  • 上記グループワークの成果発表会
  • 参加者同士の懇親会

時間配分を見るとわかるように、講義やハンズオンに加え、グループワーク課題にも多くの時間が割かれており、インプットとアウトプットの両方を意識した内容となっていました。また、弊社以外にも、多くの企業から新卒エンジニアが参加しており、私たちは、それぞれ別のチームに分かれて、他社の新卒エンジニアの方々3〜4人と一緒に課題に取り組みました。

この記事では、私たち5人が、どのような観点からグループワーク課題に取り組んだかご紹介したいと思います!各チームのアウトプットの違いにも注目して頂けると面白いと思います。

課題:大規模チャットツールを作ろう!

初日に発表されたグループワーク課題は、「新卒入社した会社でチャットサービスを立ち上げることになったので、そのアーキテクチャを考える」というものでした。なお、その会社の既存メンバーは全員退職予定ですが、全世界規模のサービスを半年後にリリースする計画はそのままであるという設定が付け加えられています。 AWS の各種サービスをうまく活用し、新卒メンバーだけで半年後のローンチを目指すことになりました。

サービスは日本・アメリカの2リージョンで展開し、Web ・ Android ・ iOS のマルチプラットフォーム展開を要求されています。必須機能として、チャット機能や動画・画像の送受信、アカウントや友達・グループ管理を実装する必要があり、それに加えて、Nice-to-have な機能として、通知・既読・スタンプ・検索といった機能が挙げられています。パフォーマンス要件としては、チャット流量が1秒あたり10000メッセージ、データ流量が1秒あたり 1GB と想定されています。また、データ保存期間は1年間となっています。

各チームの成果の紹介

グループワーク課題では、上記の要求を満たすようにアーキテクチャを設計する必要があります。ただし、アーキテクチャを設計する上では、実現可能性のみならず、開発容易性やコストなど、さまざまな観点から考える必要があり、どの観点を重視するのかによって、最終的に決定したアーキテクチャにも違いが出てきます。私たち5人のいたそれぞれのチームの成果をご紹介したいと思います。

横山(チームA)

チームAでは、与えられていた背景をもとに、サービスをいかにして成り立たせるかということを意識しました。

今回のワークショップでは、既存社員が全員退職する中で新卒社員であるチームのメンバーだけで、半年でサービスをリリースしないといけないというタイトなスケジュールが与えられていました。チャット機能を実現するには双方向通信の実装が必要であるとわかりましたが、メンバーの多くは Web アプリケーション開発のエンジニアで Web での双方向通信の開発経験がありませんでした。

そのため、チャット機能は Lambda と API Gateway で実装し、一方で、今後のサービスの拡張性を考えてアカウント管理やチャット内検索などの機能は ECS 上に構築するようにしました。

また、サーバーのモニタリングや、Lambda の実行失敗、失敗したキューはデッドレターキューに流すなど実際にサービスの運用を想定した構築を意識しました。

ここまで大きな1つのサービスを構築することを考えて、アーキテクチャ検討を行ったことがなかったのでとても良い経験になりました。

山中(チームC)

チームCでは、必須機能に限定して、アーキテクチャを検討しました。基本的には AppSync を用いた GraphQL API を構築しました。また、特に工夫した点としては、次の2点を挙げました。

  • 直近2ヶ月のメッセージデータのみを DynamoDB に配置し、残りのデータは S3 に保管する
    • チャットのメッセージデータは、直近のものは頻繁に参照されるのに対して、過去のものはほとんど参照されないという特性があると考えられます。そのため、直近のデータのみを DynamoDB に配置し、残りは S3 などの安価なストレージに移すことでコスト削減を実現できます。私たちの試算では、直近2ヶ月分のみを DynamoDB に保管した場合、1年分のメッセージデータを全て DynamoDB に保存した場合に比べ、月2400万円のコスト削減になることが分かりました。
  • 動画変換に Elemental MediaConvert を利用する
    • AWS Elemental MediaConvert とは、動画データを各スマートフォンやタブレット端末に適した動画データや、ストリーミングデータに自動的に変換してくれるマネージドサービスです。マルチプラットフォームに対応する上では動画の変換処理が必須となるものの、処理を自分たちで実装するのは難しいと考えられたため、 MediaConvert を用いて楽をしようと考えました。

後者の工夫に関しては SA の方も想定していなかったようで、深いところまで検討できていると高評価をいただくことができました。他の企業の新卒のチームメンバーとともに、深いところまでアーキテクチャについてディスカッションでき、とても楽しむことができました。

原田(チームH)

チームHは全員 AWS 初心者だったため、既存のアーキテクチャをもとに各サービスがどんなものか調べ、必要に応じてサービスを加えたり構成を変更したりして進めました。例えば、一口に「チャットメッセージを DynamoDB に格納する」といっても、アメリカと日本でどのように同期を取るかは AWS のドキュメントを読みながら考えました。今回は Global Table という複数のリージョン間でデータベースを同期する機能を使うことにしました。

最終的なアーキテクチャはこのようになりました。認証機能は Cognito を利用し、ホスティング・デプロイ・ UI 開発は Amplify を使います。データについては、画像・動画といった静的ファイルは S3 の Intelligent Tiering で格納し、チャットメッセージは書き込みの速さを考慮し DynamoDB に格納します。自分たちのチームでは、アーキテクチャ以外に、実際に運用するにあたってクォータ制限に引っかからないかを検証しました。例えば、Dynamo DB は書き込みには 1テーブルあたり 40,000 write request units・読み込みには 1テーブルあたり 40,000 read request units というデフォルトのクォータがあります。この request unit とはデータの単位で、1 read request unit は「1秒あたり 4KB のデータを読み込める」というデータです。例えば、2KB のデータの read 操作は 1 read request unit に納まりますが、6KB のデータを読み込むときは 2 read request unit 必要です。今回は、 Read/Write 共に DynamoDB クォータ内に収まることがわかりました。

研修は3日間頭を使いっぱなしだったので大変でしたが、チームメンバーとたくさんディスカッションができて楽しかったです。 AWS についても、何がなんだかわからない状態からメジャーなサービスの概要が分かり、アーキテクチャ図の読み方もわかるようになり良かったです。

喜屋武(チームJ)

チームJでは、主要な機能を重点的に考え、サービスとして成り立たせることを目標にアーキテクチャを考えました。そのためマルチリージョンなどは今回のアーキテクチャではスコープ外としました。

リアルタイム性を求められるようなチャット機能に関しては、 Lambda はコールドスタートした際に数100ms掛かる可能性があるため使わず、ECS ( on Fargate ) で常駐させることでリアルタイム性を損なわないようにしました。一方で、レスポンスの時間がある程度許容される過去のチャットへの参照などは Lambda を用いることでサーバのメンテナンスコストを下げるようにしました。このようにユースケースごとにアーキテクチャの選定をし構築を行いました。

今回の課題では大規模なアクセスを想定したアーキテクチャについて考えましたが、想像以上に考えることが多く難しかったです。ですが、学びも多く(新規接続数やデータ容量など)非常に良い経験が出来たと思います。

宮崎(チームL)

チームLでは、マルチリージョンで低レイテンシな通信を実現するインフラ構成をテーマにしました。SA の方々と密に会話できる貴重な機会でしたので、あえて難しい構成を目指しました。構成を議論するに当たって特に気を付けたことは、リージョンや VPC を跨いでも通信可能か、データの同期は問題なく行えるかということでしたが、認証で使用する Cognito や 画像などを保存する S3 はリージョン間でデータの同期がどのように行われるかを調べきれなかったため、片方のリージョンのみに配置することにしました。これにより、一方のリージョンがダウンしてももう一方のリージョンでサービスを継続できるようなアクティブ/アクティブ構成にできなかったのは個人的に悔いが残る点でした。また、 DynamoDB に全てのデータを入れる構成のため、金銭的なコストやパーティションキーの設計で困難を強いられる構成となってしまいました。

これほどクラウドのインフラ構成について考えたのはこの研修が初めてでした。何より SA の方と AWS 各サービスの細かな仕様について議論できたのは貴重な経験で、普段はフロントエンドのコードばかり書いている私にとってインフラ層に興味を持つ良いきっかけになりました。

まとめ

今回の研修では、ディスカッションを通じて、アーキテクティングの際に考慮しなければいけないポイントをおさえることができました。今後、システムアーキテクチャを検討する際に役立てていきたいと思います。

ECS や Amplify のハンズオンでは、簡単に Web アプリを構築できることに驚きました。 AWS をはじめとするクラウドサービスを賢く使いながら、ビジネスに貢献できるエンジニアを目指していきたいです。

また、今回の研修を企画していただいた AWS Japan 様、研修内で一緒になった他社エンジニアの皆様にもこの場を借りて御礼申し上げます。

 

 

ラクスルでは、AWS を利用して Web サービスを展開しており、モブプロなどを通じチームメンバーとディスカッションする環境も豊富にあります。また、技術書買いホーダイ制度など、エンジニアの学習を支援する環境も整備されています!ラクスルで一緒に働いてみたいと思ってくださった方は、こちらのページ (https://recruit.raksul.com/) をご覧いただければ幸いです!

 

 

※本記事で使用されているアーキテクチャ図ではAWS提供のアーキテクチャアイコンを使用しております。また、アーキテクチャ図は他社エンジニアの皆様との共同作成したものを掲載させていただいております。