AWS re:Invent Recap 2023に登壇しました
こんにちは。
こんにちは！クラウドサーカス開発部の杉井です。
AWS re:Invent Recapで広告・マーケティングテクノロジー向けセッションで発表しました。その内容を本記事で紹介させていただきます。
開発体制の強化（p28~）
『LESSAR』は、WebARの技術を活用したサービスです。WebARの技術を使ったサービスは、ビジネスにおける成功事例の情報がほとんどありません。また、顧客見込みや売上見込みが不透明なことが多いです。今回の登壇では、最初から大規模なシステムは作らずに、スモールスタートし、その後、障害対応やシステム規模拡大に伴って、AWSの機能を追加・拡充しながら進めました。
開発スタート時のインフラ構成に問題ありませんでしたが、下図のように、計画や設計など開発体制に問題があったため、アジリティが上がらず、なかなかサービス品質が向上しませんでした。
[問題点]
1. 顧客フィードバック不足：顧客の声を吸い上げる方法が不足
2.正解がわからない：WebARシステムの情報が少なく、どう改善すればいいかわからない暗中模索な状態となる
3. 手作業が多い：テストやリリースを手作業で行ない、かなり工数がかかっていたため、リリース回数を増やせなかった
これらの課題を解決し、アジリティを向上させるためにまず導入したのはCI/CDです。これでUnitTestの自動化とリリースの自動化が可能となり、素早いサービスリリースが可能となりました。
また、弊社のカスタマーサクセスマネジメントツールであるFullstarを利用して顧客から直接フィードバックを得られる仕組みにしました。
この２つをさらに加速させるためにScrum開発を導入し、2週間に1回のリリースを行い、顧客のフィードバックを受けて早期改善していけるような体制にしたことで、質の高いサービス提供が可能となっています。
課題解決におけるAWS活用事例(p35~)
システムを運用していく中で発生したさまざまな問題点・課題の中からAWSの活用事例を紹介します。
EC2アクセス処理負荷軽減対応(p38)
EC2の負荷軽減の対応は一般的な内容です。EC2へのアクセス処理負荷に応じてリソースを調整して負荷を軽減しています。
LESSARが通常よりも高いシステム負荷への対応が必要となるのは、ハロウィンやクリスマスなど大型のARイベント企画として活用していただくケースです。
このような際、ほとんどの場合は、EC2の自動スケールアウトで対応できますが、スパイク負荷を考慮して、事前にスケールアウトを実施する運用も併用しています。
同時アクセス負荷による障害対応(p42)
先ほどは、EC2の負荷軽減について対応しましたが、次は短期間でセッション数が上限に到達した場合の話です。
これまでの課題として、利用されるイベントの実施方法によっては、短期間で日本中からアクセスが集中する場合があり、想定以上のアクセス数にシステムが耐えられませんでした。
通常アクセスの場合、EC2からRDSへアクセスして、AR情報を取得します。
大量アクセス時のEC2の台数はスケールアウトで増えるのですが、RDSが単一障害点となってしまいます。具体的にはRDSセッション数上限に到達して、EC2からRDSへの接続待ち状態が発生します。
解決策として、一度RDSへアクセスして取得したデータをElasticCache（Redis）へキャッシュし、２回目の取得はRedisから取得するように修正しました。AR情報は頻繁に変わるものではないため、Redisなどキャッシュを使い、可能な限りRDSなどの単一障害点となり得るような箇所のアクセスを減らすというアプリケーション構成を心がけました。これにより、アクセス数の上限を上げることができました。
Log処理ロスト問題の事前改善(p48)
同時アクセス負荷の障害後、他にボトルネックがないか調査したところ、Log処理に問題があることが分かりました。
LESSARは、一般的なWebサイトのようなスクロールではなく、ページ内でARを表示した後に写真撮影をしたり、リンクを埋め込んで遷移させるなどAR特有のデータ特性があります。
LogはEC2経由でRDSへ格納する仕組みでしたが、上記のようなデータ特性だと短時間に大量のLog情報を収集する必要があり、EC2やRDSの障害発生によってLogが失われる恐れがあります。
これを解決するために、LogをEC2で直接受け付けるのではなく、API GatewayとSQSを追加しました。漏れなくLogを収集し、その後、順次EC2でLogを処理するように修正したことにより、Logをロストしない仕組みになっております。
データ分析(p51)
データ分析については、システム利用者が増えるにつれて、LESSARのデータを活用できないか？という相談が社内から増えてきました。そこで、利用傾向を把握してフィードバックできる仕組みを作れないかと考えました。
最初はLESSARのシステム管理画面にダッシュボード形式でデータを視覚化し、そのデータのダウンロードもできるように改修しました。
その後も段々と要望が増え、条件が複雑化したため、システム改修では追いつかず、コストも大きく掛かるようになりました。
そこで、LESSARからデータを取り出して、AthenaやQuickSightを使って、分析できるように再構築しました。この対応により、社内の各部署からの要望（例えば、「今どういうふうに使われていますか」など）に応じて速やかにデータを加工および分析できるようになりました。
Athenaで集計したデータは、基本的にUXの改善に役立てています。例えば、「企業様のARページにエンドユーザーがアクセスされただけで終わったのか？」や「エンドユーザーが写真を撮っているのか、ちゃんとリンクまで飛んでいるのか？」など各クライアント企業様のエンドユーザーデータを可視化して、LESSARを成長させていくための分析ツールとしてデータを活用しています。
今後の展望
AWSには様々な機能があります。開発における問題解決のツールとして使いこなせるようにスキルを高めていきたいと考えております。
「どのサービスをどのように使えば、解決したい問題を解決できるか？」
そのためには、常に新しい情報のキャッチアップを続ける必要があります。また、今の環境を最大限活かすという点で、AWSチームがCCのSlackに入ってくださっているので、技術的な質問をもっとしていきたいと思います。そこで得た情報を知識で終わらせるのではなく、最終的にLESSARの開発に還元できるところまで成長していきたいと思います。
LESSARは、月間100万PVを達成しました。今後、月間100万PVから月間200万PVとなる利用見込みを想定しています。これまでの企業様の利用形態もさまざまでオフラインイベント型だけではなく、Live配信イベントなど日本中から一斉アクセスが発生する突発的な負荷が発生するケースも増えてきました。
そうなると今以上にさまざまな問題が発生すると考えられます。現在のEC2構成では限界が来ることがわかっていますし、今後増え続けるLogデータの対応やデータ分析基盤の整備、EC2メンテナンスコストやコンテンツ管理コストも取り組むべき課題は山のようにあります。
まだ構成検討段階ですが、これらの問題に対応できる新しいAWSアーキテクチャ構成を検討しています。例えば、EC2だけに頼らないサーバーレス構築の方法などです。これからも様々な要望が来ることを見据えつつ、LESSARのシステム構成をどんどん最適化していき、より使い続けられるARシステムにしていきたいです。