KDDI ソフトウェア技術部＆KDDIアジャイル開発センター（KAG）の御田です。

先週は日本における年に一度のAWSの祭典「AWS Summit Tokyo」が開催されていました！ 幕張メッセで2日間、私もCCoEチームやKAGのメンバーと一緒に現地で参加してきましたのでレポートします。

加えて、大人気セッション「アーキテクチャ道場2023！」についても内容をおさらい紹介させていただきます。

4年ぶりの現地開催！ AWS Summit Tokyo

朝の海浜幕張駅からすでに大変な人の波！ 私はCCoEメンバーの大橋、柴田と会場へ向かいました。

基調講演

広大なキーノート会場！ Re:Inventさながらです。 1時間近く前に到着したのですが、座席がかなり埋まっていました。待ち時間中はFPM田中さんによるアゲアゲDJプレイが行われています。

初日の基調講演には弊社社長の髙橋からもプレゼンテーションがありました。 その中で技術コミュニティやCCoEなどの取り組みについても言及があり、これは自社の現場メンバーにとってもいい意味での想定外でみな心を打たれていました。

KDDIブース

EXPO展示の自社ブースでは5G/MEC技術を活用して、虎ノ門にあるラジコンカーを遠隔操作する体験を行っていました。

詳細は以下の記事でも事前紹介されておりましたので、ぜひご覧ください。

映像伝送と遠隔操作における5G/MECを利用した 実証プログラムご案内

AWS GameDay

AWS Summitでは、事前登録制で実際にデモAWS環境を用いてチームでお題に対して実装チャレンジを行うゲームデーという企画がありました。

AWS GameDayを含むEXPOコンテンツの紹介

約4時間の長丁場イベントで、チームは仲間同士だけでなくその場でランダムに結成されるものも多数あり、アイスブレイクから始まっていました。

そして、弊社の末光 一貴（KDDIアジャイル開発センター / KDDI ソフトウェア技術部）の所属チームがなんと3位入賞を果たしました！おめでとうございます!!

ユーザーコミュニティの紹介（Community Kiosk）

私はAWSのユーザーコミュニティ「JAWS-UG SRE支部」の運営メンバーもしているのですが、今回のEXPO会場内のDeveloper Loungeエリアにて技術コミュニティを紹介する「Community Kiosk」のスタッフにも入っていました。

AWSの大きな特徴の一つとして、様々な会社のユーザーたちが自主的に勉強会などを開催するコミュニティが非常に盛り上がっているという点があります。

JAWS-UG（AWS Users Group Japan）をはじめ、日本全国の会場もしくはオンライン配信にて毎週たくさんのイベントが行われていますので、ご興味のある方はぜひ自分にあったコミュニティを探してみてください。

AWSユーザーグループ一覧

大人気セッション「アーキテクチャ道場」

2日間の中でも特に人気を集めていたセッションの一つが、AWS Japanのチーフストラテジスト内海さんによる「アーキテクチャ道場2023！」です。 私も昨年のAWS Summitで観たときから大ファンになり、今回も最前列の席を押さえてガチ勢として受講していました。（ちなみに20分前に入場しても既にほぼ席が埋まっていました…）

30分という短めのセッションなのですが、与えられたお題に対してAWS Japanのソリューションアーキテクト（SA）さんがガチでアーキテクチャを考え、それに対してホストの内海さんがガチでフィードバックをするという流れを2本連続で行う、大変濃厚なコンテンツです。

お題①「ゲームのバックエンド基盤コントロールプレーンを作れ！」

1つ目のお題はオンラインボードゲームの新作公開に向けて、バックエンド用のサーバーリソースを弾力的に調整できるようなコントロールプレーンをAWSを利用して設計せよというものです。

挑戦者はSAの竹本さん。まずは問題を「サーバーとセッションのマッピング」と「オートスケーリング」の2つに分解するところから始めます。

サーバーとセッションのマッピング

セッション割り当てのために「インスタンステーブル」と「セッションテーブル」の2つを用意します。 セッションが新規作成された際はセッションテーブルにレコードを追加するだけでなく、インスタンステーブル内の当該インスタンスの「保持セッション数」属性もインクリメントしていき、インスタンス毎の上限セッション数を超過しないようにする仕組みです。

このとき想定される課題として、セッション数が増えるとDBへの書き込み負荷がボトルネックとなってしまうという点です。これを解消するため、インスタンスをツリー構造で階層管理することによってテーブルの全体スキャンを避ける手法をとりました。

オートスケーリング

セッション数が溢れないようにスケールアウトを行うため、Auto Scalerアプリケーションを稼働させてインスタンステーブルをポーリングし、全インスタンスの保持セッション数が上限を超えた場合に追加インスタンスを起動させる方式が最初に提案されました。 スケールインの方は実は難しいのですが、インスタンステーブルに「新規セッション割り当て可能フラグ」を設けることによって、新規セッションを防ぎつつドレイニングを行い安全に不要インスタンスを停止させるというアイディアです。

ここで想定される課題は、セッション数のポーリング時にセッションテーブルへの読み取り負荷がボトルネックとなってしまうことです。これに対応するため、インスタンス全体を監視するのではなく各インスタンス単位でオートスケーリングを行う方式を採用することとしました。保持セッション数が閾値を超えたインスタンスは、階層管理のなかで自分の子インスタンスを増やすという戦略です。

AWSアーキテクチャ案と質疑応答

これらをAWSで実現するためのサービス選択として、セッション管理にAPI Gateway & Lambda、オートスケーラーにLambda、そしてテーブルにDynamoDBを採用されていました。

内海さんからのQAの中では、以下のようなケースについて補足されていました。いずれもハイレベルな突っ込み＆回答です！

• 障害などで各テーブル間のインスタンス台数に不整合が発生した場合は補償トランザクションで解決する。
• 誤ったセッション割り当てが行われた場合に備えてバックグラウンドでスイーパープロセスを稼働させる。
• 長期的な障害でリカバリ処理が繰り返されることを防ぐため、ハートビートを稼働させタイムスタンプが古いインスタンスへは新規セッションを割り当てない。

このケースはゲーム以外にもビデオ会議のホストサーバーやストリーミングのオリジン管理等でも応用できるということでした。そしてお題では禁止となっていましたが、本当はマネージドサービスであるAmazon GameLyftを使うと楽に解決できるケースです。

お題②「ユーザー管理システムを波風立てずクラウド移行せよ！」

2つ目のお題はモバイル通信事業者がユーザー管理サービスをAWSへリフト＆シフトするうえで、クライアント側のシステム開発ペースに合わせて新サービスへワークロードを移していくにはどうすればいいか？というものです。…まるで基調講演のよしみで弊社を題材にしていただいたかのようですね（笑）

挑戦者はSAの石井さん。まずは課題を整理し「サービス機能」「移行方式」「開発/運用容易性」の３つの要求へ分類しました。特に移行方式のウェイトが高いため、以下の4つのフェーズに分割して説明されていました。

1. インターフェース移行
2. アプリケーション移行
3. データストア移行
4. クライアント移行

段階移行の流れ

インターフェース層の移行

• まずはインターフェース層を移行。クライアントの早期移行を促すため新システム側でRESTエンドポイントを迅速に提供し、バックエンドで旧システムを継続利用できるようにします。

アプリケーション層の移行

• 新システムのアプリケーション層が開発完了し次第、インターフェース層のRESTゲートウェイの呼び出し先を新アプリケーションへ切り替えます。この段階ではデータストアは旧システム側を使い続けます。
• 新アプリケーションが無事に稼働しはじめたら、旧システムのインターフェース層の呼び出し先も新アプリケーションへ切り替えます。

データストア層の移行

• データストア層の移行は厄介です。本システムはSLAが高いことから、いつでも切り戻しができるよう新旧データストアへアプリケーションが常にダブルライトを行うこととしました。
• 新旧データストア間での不整合に備えては、「トランザクション管理テーブル」を設けて不整合の検知＆復旧を試みます。
• ダブルライトによって新データストア上のデータが増えていき、アクセスが減る旧データをバックグラウンドで移行します。その後、新データストアのみのシングルライトへ変更します。
• トランザクション管理テーブル上に滞留したデータは旧データストアを正として再移行します。

クライアント層の移行

• クライアント側は任意のタイミングで新システムへ向き先を変更すればOKです。

AWSアーキテクチャ案と質疑応答

これを実現するAWSサービスとして、インターフェース層にAPI　Gateway、アプリケーション層にLambda、データストアは旧システムからの開発・運用容易性を考慮してKeyspacesを採用していました。

内海さんからのQAの中では、以下について補足されていました。

• ダブルライト方式のデメリットとして、書き込みレイテンシーの増加やデータストアの可用性低下（片方でも落ちたらNG）は認識が必要。
• ダブルライトの代わりに旧DBをキャプチャー（CDC）する場合、データストア全体の可用性は向上するものの更新追いつきのためにデータストア停止が必要となる点について考慮が必要。

ちなみに今回のように旧システムのインターフェース層から新バックエンドへリダイレクトする方式のことをレガシーミミックパターンというそうです。よく比較される移行戦略としてストラングラーフィグというパターンもあり、これらについても別記事でまとめてみましたのでご興味あれば是非ご一読ください！

システム移行戦略「レガシーミミックパターン」＆「ストラングラーフィグパターン」とは？

さいごに

今回のようなイベントは「現地行くの面倒だしストリーミングで見ればいいや…」とも思ってしまいがちですが、実際に足を運んでみると日本中のAWSユーザーたちの半端ない熱量を肌で感じられたり、様々な会社に所属する人たちと直接会話して情報交換することによる忘れられない学びや発見が多数あり、本当に充実した2日間となりました。会場にてお話しさせていただいた皆さま、ありがとうございました！！

※実を言うと日中だけでなく、イベント終了後もE-JAWS（Enterprise AWS Users Group Japan）のパーティやAWS Community Buildersの会合があったりと、他社メンバーとのネットワーキングも盛り上がっていました。

ちなみに私は翌日も九段下にてAWS User Community Leaders Meetupに参加していたのですが、日本全国で様々なAWSコミュニティを運営する仲間たちと交流し議論や情報交換を行うことができ、3日連続で刺激的な週末でした。

自社の若手メンバーをはじめ、周りの優秀な仲間たちももっと社外の広い舞台に出ていき活躍できるよう、後押しする活動もガンガンやっていこうと思います！