Da Vinci Studio 第 2 サーバー部の桃原です。 6月16〜17日開催の AWS JumpStart という初学者向けのワークショップに参加したので、内容や学んだ事をまとめていきます。
AWS JumpStart について
今回参加した AWS JumpStart は AWS 初学者のエンジニアを対象とした実践的なプログラムです。 単なるAWSサービスの学習だけでなく、要件に合わせて適切なアーキテクチャを検討・設計する経験を積む部分にフォーカスした内容です。
参加の経緯
弊社のインフラは AWS をメインとして使っているのですが、インフラ基盤部とやりとりする際のサーバー部の AWS 知識量の差が課題に挙がっていました。 ちょうどそのタイミングで AWS の方からワークショップの案内があったので、サーバー部のメンバーが上司に確認したところ希望者は業務時間内で参加させてもらえることになり、サーバー部から7名が参加してきました。
事前準備
イベント開催前に事前学習として2つで合計3時間半の動画を共有していただきました。どちらの動画も分かりやすく AWS やアーキテクチャ設計について網羅的に学ぶ事ができました。 1つ目の動画では、機能要件と非機能要件についての説明の後、アーキテクチャ設計で意識すべき観点についての内容でした。 2つ目の動画では、よく使われるサービスについて学ぶ事ができました。
イベントの概要
イベント当日にも軽い事前学習動画の振り返りがあり、その後に4人チームに別れてアーキテクチャ設計を行なっていきました。このアーキテクチャ設計がメインコンテンツで、2日目には発表会もあり、他のチームが設計したアーキテクチャ図を見ることもできました。
ハンズオンもあり、AWS コンソールを使って予め用意していただいた単純なアーキテクチャ図から実際にアプリをデプロイしてみたり、可用性の確認のために RDB をフェイルオーバーさせてみたりしました。 「設定次第では高い料金が発生してしまうかもしれない」や、「1年の無料枠をまだ使いたくない」等のハードルがある方には貴重な経験になるかと思います。
チームでのアーキテクチャ設計
流れやチームの雰囲気
アーキテクチャ設計の時間では4人のチームに振り分けられ、チームごとに AWS の会議ツールの Chime でワークショップを進めました。 普段の業務では通話のみという方が多かったので終始ビデオオフでしたが、自己紹介の時から発言も多く、楽しく議論しながら進める事ができました。 アーキテクチャ設計にはホワイトボードツールの BlueSpace を使いました。よく使われるサービスのアイコンが準備されていたので、すぐに設計に取り掛かる事ができました。 AWS の方に20分×3回質問したりフィードバックをいただけるオフィスアワーという時間があったので、疑問を解消できたり新しい発見がありました。
要件
アーキテクチャ設計をするにあたって、サービスやシステム要件の説明がありました。
- LINEのようなチャットサービス
- 想定提供規模
- 平均チャット流量: 500re/sec
- メッセージ保存期間: 1年
- ピーク時間帯: 日本時間の夕方
- 提供エリア日本: 日本
- 提供プラットフォーム: web
- 必須機能
- チャット機能
- 数秒以内のリアルタイム性
- 友達管理/グループ管理
- 画像/動画
- チャット機能
- オプション機能
- 通知
- 既読管理
- スタンプ
- チャット検索
アーキテクチャ設計とオフィスアワー
アーキテクチャ設計が始まると、チャットサービスの実装事例について各自で調べて共有するところから始めました。 「友達機能は RDS、チャットはリアルタイムの読み書きが必要なので NoSQL や AppSync を使った方が良さそう。」「アプリプッシュ通知には PinPoint が便利そう」など使えそうなサービスのイメージを固めました。 1回目のオフィスアワーでは、マルチ AZ についてまだ考えられていなそうというフィードバックをいただいたり、質問にも答えていただいて、WAF を設置した方がいい場所や VPC の外側に置けるサービスについて等知る事ができました。
2日目は DB 設計や DynamoDB、CloudWatch の検討から進めていきました。 2日目のオフィスアワーでは、S3 に認証機能がついていないというフィードバックや設計をシンプルにする提案をいただきました。 開発環境についての質問をして、環境毎に AWS のアカウントを作った方が料金管理やロール付与が楽になるというベストプラクティスを教えていただきました。 2日目の後半には発表の準備をしながらオプション機能や要件を満たしているかについて議論していきました。
設計したアーキテクチャ図とくふうした点
最終的に私たちのチームで提案したアーキテクチャ図は以下のようになりました。
チャット機能に AppSync と DynamoDB、友達/グループ管理に EC2 と Aurora、画像/動画を保存するために S3 を採用しました。 オプション機能であるスタンプ機能、チャット機能までは組み込まれていません。
このような構成にした理由やくふうした点は以下になります。
- 可用性
- アベイラビリティゾーンを2つに分けて(Multi-AZ にして) EC2 や Aurora を配置する事で、1つのアベイラビリティゾーンに問題があった場合もサービスを継続できるようにしました。
- また、Aurora を使っているのでマスタに問題があっても、レプリカへの自動フェイルオーバーをしてくれます。
- スケーラビリティ
- 運用をしながらの調整という形になるのですが、CloudWatch を確認して EC2 と Aurora のオートスケールやスケジュールを設定する方法を考えました。
- セキュリティ
- ELB、CloudFront、AppSync に WAF(ファイアウォール)を適用する事で不正なアクセスを制限するようにしました。
- S3 には Cognito を使用して、認証されたユーザーにのみ画像や動画を見れるようにしました。
- パフォーマンス
- リアルタイムの読み書きが求められるチャット機能には DynamoDB を使用しました。
- 読み込みがメインの友達機能は Aurora のレプリカを使って負荷分散するようにしました。
また、将来の改善余地についても議論しました。 本番環境のみのアーキテクチャ図になっていたので、環境毎にAWSアカウントを用意して、開発環境やステージング環境を作成したいという話が出ました。CI/CD も導入したいという話もしていました。
成果発表
2日目の後半には4チームずつに別れて成果発表会がありました。 私たちのチームはオフィスアワーで指摘していただいた所を修正して新しく指摘される部分も無かったので、最低限考慮するべきところはできたのかなと思います。 オプション機能までは設計できなかったのと、私たちのチームとはかなり構成の違うチームもあったので、様々な構成からメリットやデメリットを書き出して議論できるようになりたいと思いました。
私のチーム以外でも Da Vinci Studio メンバーが参加したチームが2つあるので、そちらで提案したアーキテクチャ図も紹介します。
私たちのチームと大きく違うのはサーバーレスな点で、Lambda などのマネージドサービスを利用した構成にしていました。 私たちのチームではオプションであるチャット検索機能まで考慮できていなかったので、OpenSearch の説明は勉強になりました。
4人全員が Da Vinci Studio のチームのアーキテクチャ図です。 こちらもサーバーレスで、機能ごとに Lambda を使っているのが印象的でした。 運用や開発のしやすさも考慮していて、バックエンド側は SAM (サーバーレスアプリケーションモデル)を採用する事で CloudFormation を使ってインフラ構成をコード化し、デプロイをテンプレート化できるという事でした。
まとめ
今までは AWS サービスの理解度が足りず、社内のインフラ構成を見てもサラッと流してしまっていたのですが、今回のワークショップで主要なサービスであれば AWS のアーキテクチャ図を見て何のサービスが使われていて、設計の意図も分かるようになりました。さらに、小さい機能やゼロからサービスを作る際には自分でアーキテクチャ設計をしたくなりました。
最後になりますが、Da Vinci Studio では一緒に働く仲間を絶賛募集中です。 興味のある方は こちら か recruit@da-vinci-studio.net までご連絡ください。
