はじめに

こんにちは、FIXERの石井です。

今日は先日AWS Summit に参加したので、そのときの話をブログにしました。

筆者がその時に感じた印象を含めて書いているので、セッションの話者がそのまま発言した内容ではなく、筆者が解釈した内容とご理解の上でお読みください。

AWS Summit について

AWS Summit は世界各国で開かれる AWS を学ぶことができるイベントです。

日本では AWS Summit Tokyo として、幕張メッセで2023年4月20日-4月21日の2日間で開催されました。

今年は4年ぶりのオフサイトでの開催とのことで、現地参加できてよかったです。

参加できなかった人も後日オンデマンド配信が行われるので、ぜひご覧ください。

https://aws.amazon.com/jp/summits/tokyo/

参加してきたセッション

KEY-02 基調講演：アイデアを形にし、これまでにない価値を届ける

AWS-49 金融機関に求められる レジリエンスの AWS 環境での 実装手法

CUS-42 リアルタイム性と 40% の コスト削減を両立 | 国内最大級 メタバースプラットフォーム cluster における AWS 活用

に参加してきました。

KEY-02 基調講演：アイデアを形にし、これまでにない価値を届ける

基調セッションでは、AWSを学ぶためのイベントらしく各サービスの紹介がふんだんに盛り込まれていました。それもただ各サービスの紹介をするだけでなく、初めてAWSに触る人でもサービスの魅力が伝わるように工夫がされていました。（セッションを見ていた時は話を追うのに必死であまり意識してなかったですが、今思い返すとよく練られているなと感じます。）

サービスの紹介の流れとしては、Amazon Bedrock という今話題のAI関連の新しいサービスの紹介から始まり、AIの基盤となるデータを保管・活用するためのサービスとして、Amazon S3 や Amazon RDS などのデータを取り扱うサービスの紹介や、データから得られたヒラメキを形にするサービスとして、Amazon EC2 や AWS Lambda などの計算処理を行うサービスの紹介が行われました。

AWSを活用している企業様からの事例として、全日本空輸株式会社様から同社で使われている「BlueLake」というデータ活用基盤の紹介や、PayPayカード株式会社様から同社の基幹システムをAWSに移行した事例の紹介が行われました。

感想：

基調講演を聞くために普段より数時間早起きしたんですが、現地で聞きに行った価値はあったと思います。

2日目のセッションの中では一番人が集まるセッションだったため、インパクトもすごくありました。

企業が開催する大規模なオフラインイベントは初参加だったんですが、初セッションがこちらでよかったです。

AWS-49 金融機関に求められる レジリエンスの AWS 環境での 実装手法

AWS-49のセッションでは、高可用性、ディザスタリカバリを考慮したインフラ構築の手法について話がありました。

AWSで可用性と聞くとよくあるパターンとして、マルチAZ構成があります。ただ、こちらの手法だとリージョン単位で障害が起こる（つまり、AZ内全体で障害が発生してしまう）とシステムが停止してしまいます。

それを防ぐために、リージョンでも冗長を行うマルチリージョン構成、これについて考えていくというお話でした。

具体的には、下記の表の５つのパターンについて説明がありました。

それぞれを補足説明したものが下記になります。

• No1：ディザスタリカバリの要件が満たせればよく、高可用性は重視していない場合に向いています。

  リージョン単位の障害時への準備として、ヘルスチェックやルーティング、フェイルオーバー/フェイルバックの考慮が必要になります。

• No2：レジリエンスではなくガバナンスの対応として、データローカリティを担保する場合に向いています。

  切り替え部分はデータベース内のデータになるので、フェイルオーバー/フェイルバックの考慮が必要になります。

• No3：読み取りアクセスが多く遅延が許されない場合に向いています。

  フェイルオーバー/フェイルバックの考慮に加えて、書き込み後の読み取り一貫性を担保する必要があります。

• No4：読み取りアクセスが多く遅延が許されない場合に向いています。

  No3 との違いとしては、それぞれのリージョンへ書き込みが行われるため、リージョン単位の障害が起こりデータが失われても、もう一方のリージョンでデータが保管されているため、RPO=0、つまりデータが失われないことを保証できます。そのため、決済関連システムに向いています。

  データベースのレプリケーションはないのでフェイルオーバー/フェイルバックの考慮は不要ですが、システムでデータの不整合が起こらないよう操作の冪等性やデータの原子性を担保できるよう設計する必要があります。

• No5：読み取りも書き込みも同様に多く遅延が許されない場合に向いています。

  フェイルオーバー/フェイルバックの考慮は不要ですが、データがレプリケート時のコンフリクトの解消や書き込み後の読み取り一貫性の担保などが必要になります。

セッションでは、ルーティングの方式の説明と、実際の事例を踏まえたマルチリージョンの考え方の説明がありましたが、あまりにも長くなりすぎてしまうので、ここでは割愛します。

感想：

サイレントセッションという形式で、座席に置いてあるレシーバーに受付でもらったイヤホンを接続して聞くタイプのセッションでした。イヤホンで耳をふさいでいる関係上、周りの雑音がほぼ入らないので、セッションに集中しやすい形式だと思いました。

セッションについての感想ですが、スライドでAWSサービスベースの説明があり、実際の事例もあったため、設計にすぐ活かせそうでよかったです。考え方自体は他のクラウドプロバイダーでも応用が利きそうな知識だったので、とても有意義な時間を過ごせました。

CUS-42 リアルタイム性と 40% の コスト削減を両立 | 国内最大級 メタバースプラットフォーム cluster における AWS 活用

いままでのセッションはAWS社員の方がメインのセッションでしたが、こちらは企業の方がメインのセッションです。

セッションの内容としては、メタバースプラットフォーム cluster の特徴の紹介とAWSサービスの構成図も含めた cluster の各機能の紹介を経て、どのようにしてコスト削減に至ったかという話になります。

最大40%コスト削減に至った方法としては、メタバース空間を維持するための使っているEC2インスタンスを、Graviton という Amazon EC2 で使えるプロセッサを使ったインスタンスに切り替えることで実現しています。

Graviton というプロセッサ自体は一般提供されているものですが、クラウドに精通していても最適なサービスや構成を選ぶのはなかなか難しいです。

クラスター株式会社様はAWS定例会としてSolutionArchitectの方と月1回程度の相談できる場を用意してもらい、そこでコスト削減の方法として Graviton2 を紹介してもらったという経緯で、Graviton の導入が始まったとのことでした。

Graviton だとCPUアーキテクチャが従来のインスタンスと異なるという問題がありましたが、Go言語を使用して開発を行っておりクロスコンパイルでその問題はクリアできたため、CI/CD周りの調整と移行後のテストの工数だけで済んでいます。

このようにして、性能を落とすことなく見事にコスト削減を実現することができたとのことでした。

感想：

セッションのスピーカーは、クラスター株式会社のCTOの方で、経営陣の人がお話ししていただけるのは豪華だなと思いました。

弊社でも metaverse cloud としてメタバースプラットフォームを提供していますが、Azure と AWS で違いがあるのでなにか吸収できるものがないかなと思って見てきました。

今回の事例ではGo言語を使うことで可搬性をうまく確保していましたが、同じようによりよい設計思想に基づいた開発を行うことで、ビジネス的な価値を創出する作業にフォーカスできるのは大事なことだなと感じています。

終わりに

結構気合が入った長めの体験レポートになりました（全体で4000文字超えてます）

ここまで読んでいただけてありがとうございます。

AWS Summit Tokyo で3つのセッションを聞いて感じたこととしては、現地セッションだと普段と違う環境にいるので集中しやすいなと思いました。オンデマンド配信で自宅で聞いたり職場で聞いたりする時と比べると、周りの人もセッションを学びに来ている人ばかりなので集中しやすい場になっていると思います。

あとは、セッション以外にも EXPO があり、コンテンツが凄く充実している点もすごくよかったです。普段知っている企業や逆に知らない企業もいろいろ聞いて回れるのも、現地参加の魅力だと思います。

AWS Summit Tokyo での心残りとしては、前半の方にセッションを聞きに回っていたら、後半EXPO を周りに行った時には、いろんな記念品が品切れになっていたことですね。こういうイベントの EXPO を見に行くときは、セッションを詰め込みすぎず午前中の早い段階で回りに行けるようにするとよさそうという学びを得ました。