2024年12月最初の週にAWS最大のグローバルイベントにして世界最大のクラウドカンファレンス AWS re:Invent 2024 が開催されました。

このブログはAWSのワーナー・ヴォゲルスさんのキーノートをラスベガス現地で目の前で見て感じたことを全3回に渡りレポートしています。

• ワーナーさんのキーノートを現地で見ました (山下) その1
• ワーナーさんのキーノートを現地で見ました (山下) その2
• ワーナーさんのキーノートを現地で見ました (山下) その3

キーノートの内容そのものを知りたい方はYoutubeで動画が公開されていますのでそちらをご覧ください。

また、そもそもAWSって何？詳しく知りたいという方は、こちらの「AWSとは？AWS認定講師が解説」をご覧ください。

Canvaの場合

オンラインデザインツールのCanvaさんが事例ゲストで登場しました。
私はプレゼンテーション資料を作成するイメージが強いですが、様々なデザインができるオンラインツールです。
最近はAI機能も話題になっていました。
2億2,000万人以上のユーザーに利用されていて、毎秒120万件のリクエストを処理して、毎日230TBづつ増加するデータを162PB管理しているそうです。

Canvaは2014年の時に数名の社員で1部屋に集まって開発をされていました。
お客さんが増えたりニーズが増えて機能を追加していくようになったら、マイクロサービスアーキテクチャが必要になるのはわかっていましたが、まずは素早くサービスを市場投入することが重要でした。
そこで将来的にマイクロサービスに変化することを見込んだモノリスを構築して、素早く初期開発が行われました。
バックエンドはステートレスなEC2 Auto Scalingで、データベースはRDSでした。

スケールの必要性が出てきたときに、もともとマイクロサービスアーキテクチャを考慮した開発を行っていたため、複数のEC2 Auto Scalingへの分解は簡単に行われました。

次にRDSのシャーディングですが、これももともとそう設計していたため、比較的簡単に分解されました。
リードレプリカも読み取り用に効率的に使用して、負荷をスケールしたデータベースで対応しました。

そしてサービスの成長が爆発的になってきたタイミングで必要に応じてDynamoDBに移行されました。

ここは苦労されたそうです。
MySQLが突然巨大化したような状態になったが、限界まで使い続けながらシームレスな移行への準備を進めました。
MySQLのままテーブルやデータの構造を変えながらKey-Valueストアとして稼働させて、準備が整ったタイミングでDynamoDBへ移行されました。

スキーマ管理をデータベースからアプリケーション依存にしたことで、スケーラビリティを得られるようにしました。 

スケールの必要性がないシステムならこういった設計に踏み込まなくてもいいのかもしれません。
でもコンシューマーが使うシステムをスケールさせられないアーキテクチャにしてるということは、ビジネスが発展しないことを願いながら開発運用しているようなものかもしれないと思いました。

進化する力をシステムに実装することが必要なんですね。
システムを進化させる力は継続的なビジネスを維持する力とよく似ていると思いました。 

Evolvability 進化可能性

「何も変化しない世界はただの幻想」

本当にそのとおりでその進化の必要性は、遅くても数ヶ月に数回訪れます。
コンシューマーアプリだけではありません。

バックオフィスシステムももちろん変化する必要があります。
会社が新しい事業や新しいサービス、新しい料金プラン、新しい支払い方法、新しい報酬計算を提供するだけでも、システムが対応できなければそれがイレギュラー作業になります。
自動化されないイレギュラー作業は、緊張を伴う手作業、ミスによる心への負担、それらが続く過度な時間を犠牲にします。
だからシステムには進化可能性が必要です。
昔、「システムは建築と同じだから作ったら終わり、それなのに自社でエンジニアを雇うのは無駄」と言っていた人がいました。
その人が管理職をやっている部門は上記のように、過度な作業に追われながら従業員に心身の負担を強いていました。
ワーナーさんのキーノートを見ながらそんなことを思い出していました。

AWS Nitro Systemも進化するための基盤として設計しています。

徐々に温度が上がる鍋では、かえるは気づいた時に茹で上がって手遅れになります。
それと同じで少しの予兆やシグナルを見逃さないようにしなければなりません。
手遅れになる前に。
茹でガエルになる前に。

警告サインを無視してはいけません。
小さな変化のときはまだまだコントロールできるものが、気がついたときには複雑になり管理や理解が簡単にはできなくなります。

CloudWatchも2009年は複雑になり問題が起こっていました。
最初はメトリクスの受信と保存をするシンプルなサービスでした。
そこに機能が追加されていったことにより、複雑になりメガサービスになってしまいました。

シンプルなフロントエンドから、各機能のマイクロサービスをAPIにより呼び出すようにされました。
Amazon自身の1998年のアーキテクチャの話とよく似たエピソードですね。
これで部分的な作り直しもできることにより、特定の言語の制限からも開放されました。
機能追加もシンプルにやりやすくなりました。

新機能を追加する際には、拡張するか新しいマイクロサービスを開発するかの選択肢があります。
拡張はその機能追加のためだけのスピードは早いかもしれませんが、複雑性を高めやすくなる弱点があります。
新しいマイクロサービスを開発すると、シンプルに管理しやすくなりますが、開発するための労力は必要になります。
おそらくAWSの場合は、マイクロサービスチームの配置から必要になると思われます。
既存のサービスを拡張しないほうがいいサインは、担当しているエンジニアがドキュメントではなく頭の中でそのサービスの全体像を把握できなくなったときと言われていました。

S3チームの組織

S3チームのアンディさんから、組織と複雑性への対応についての解説がありました。

まず最初にS3チームは、組織の複雑さを解決したわけでないと言われました。
S3というサービスも進化し続けていて、S3チーム全体もマイクロサービスチームが増え続けて大きくなり続けています。
ベストであるために日々学んでいるから、スライドに「Every day is a learning day」と書かれているのですね。

成功しているマイクロサービスチームは常に、間違えているのではないかと不安を抱えている。
うまくいってるときこそ、不安が大きくなり、今を疑い改善しようとします。
だから、S3チームはうまくやれています。
疑えるから改善できるんですよね。
これは私も今までの大したことのない経験ですが、骨身に染みて感じています。

「これまでもずっと同じやり方でやってきたから」
これが今やってるやり方の理由だとしたら、必ず疑うべきです。
エンジニアリングに限らずどんな仕事でも作業でも疑ってきました。
私の場合はだいたいうまくいってない現場が多かったのですが、疑うから改善できました。
だいたいの場合、できたときはうまくいく最適なやり方かもしれませんが、それ以外に変化が生じたらすぐにマッチしないやり方になります。
でもそれを変えずに「今までこうだから」でやり続けると、非効率になったり、ミスを誘発したりします。

だからこそ、仕事する人は日々学ばなければなりません。
システムを複雑にしてしまうのは、変化という責任を果たさない考えや行為なのかもしれません。

「オーナーシップにフォーカスする」
自分がやりたくて、その質を高めるために何をすべきかを全力で考えて、全力で取り組んで結果を確認して再チャレンジします。
自分で選んで失敗するから自分でやり直せます。
そうしているうちに成功します。

自分で選んで自分で責任を果たす。
そうしてこそ自分の仕事を愛せますね。

ワーナーさんのキーノートを現地で見ました (山下) その3 へ続きます。