FIXER Tech Blog - Cloud

FIXER cloud.config Tech Blog

AWS Summitでの冒険：3つのセッションに現地参加して感じたこと

　本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「AWS Summitでの冒険：3つのセッションに参加して感じたこと」を再編集したものです。

はじめに

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

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

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

AWS Summitについて

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

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

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

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

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

AWS Summit Tokyo 現地に入るときの写真

参加してきたセッション

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

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

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

　に参加してきました。

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

AWS Summit 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 Summit AWS-49 Active／passive パターンのスライド

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

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

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

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

No	アークテクチャー	アクセスパターン	データストアの同期	ユースケース
1	Active／Passive	SingleWriter／SingleReader	片方向／非同期	ディザスターリカバリー
2	Active／Active	リージョン分割 （Sharding）	なし	規制（データローカリティー） 高可用性が不要
3	Active／Active	SingleWriter／MultipleReaders	片方向／非同期	結果整合性の受容 ReadHeavyのワークロード
4	Active／Active	DualWrites	なし	ReadHeavyのワークロード RPO=0
5	Active／Active	MultipleWriters／MultipleReaders	双方向／非同期	結果整合性の受容 Read／WriteHeavyのワークロード

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

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

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

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

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

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

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

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

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

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

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

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

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

感想：

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

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

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

AWS Summit CUS-42clusterプロダクト紹介のスライド

　いままでのセッションは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 を見に行くときは、セッションを詰め込みすぎず午前中の早い段階で回りに行けるようにするとよさそうという学びを得ました。

石井汰樹／FIXER
高専卒の2020年4月入社。四日市事業所所属。
インフラ関連の知見を深めていきたい。

■関連サイト

• cloud.config Tech Blogのエントリー
• cloud.config Tech Blog
• FIXER