SRE の @s4ichiです。年が明けてしまいましたが、昨年 11 月の終わりから 12 月の始めに開催された re:Invent 2022 へ現地参加してきたため、足を運んで得てきた体験をレポートとしてお届けします。今年もクックパッドから総勢5名の社員が参加してきました。
クックパッドと AWS re:Invent
クックパッドでは 2011 年ごろから AWS の各種サービスを利用しています。当時のサービスを AWS に移行するところから始め、かれこれ 10 年以上 AWS をコアに利用してきました。 re:Invent へは 2012 年から社員が参加しています。コアに利用するサービスのアップデートをキャッチアップするのはもちろんのこと、普段利用しないサービスの Workshop へ参加して知見を更新したり、AWS の開発者と直接議論やフィードバックをすることで、普段利用するだけでは見えてこない視点を養う機会になっています。
参加レポート
さて本題です。 re:Invent への参加は、参加した社員の知見更新だけでなく、帰国後に社内で実施する報告会や個々人の社内ブログ投稿を通して社内のエンジニアへ広められます。今回はそんな社内ブログに投稿されたレポートから取り上げた内容をいくつかピックアップして紹介します。
参加者それぞれ毛色の異なるセッションを聞いてきたので、それぞれの視点から書いたレポートをお届けします。今回レポートを書いたのは @s4ichi, id:sora_h, @hilinker, そして @naoki_shigehisaの4名です。
EBC (Enterprise Business Conference)
id:sora_hです。クックパッドは例年、AWS の担当アカウントチームに re:Invent を含めいろいろな機会で AWS のサービスチームとミーティング (EBC や Customer Meeting と呼ばれるもの) を組んでもらっています。re:Invent 2022 でも、複数のチームとディスカッションをすることができました。
詳細はここには書けませんが、基本的にやることは自分たちがどうサービスを使っていて、何に困っているかを持っていきます。現地ではそれに対して自分たちで workaround できる方法はあるか、サービスに機能を入れるとしたらどういう方向がいいのか、といった内容を議論することが多いです。内容は当然英語なので、基本的には事前にざっくりとした資料を作ったりして楽になるように、また限られた時間を有意義に活用できるようにしています。
担当者個人としては、re:Invent のような巨大カンファレンスはアーカイブに残らないコンテンツや機会を中心に時間を使うべきと考えていて、EBC は AWS との渉外を担当する自分にとっても、またマネージドサービスをしっかり利用している会社としても、重要なミッションです。今回も楽しく有意義な議論ができて満足しています (内容は書けないのですが)。
[NEW LAUNCH!] Using policies to manage permissions with Amazon Verified Permissions [Breakout Session]
@s4ichi です。このセッションは Amazon Verified Permissions という新機能に関するもので、その機能の説明からの技術の概要までを深堀りするセッションでした。Amazon Verified Permissions 自体も機能がかなり面白くて、簡単に言えば IAM Policy に似た記述を用いて任意のドメインに関する認証・認可を代替してくれるマネージドサービスになっています。 つまり、「ユーザーがレシピAを見るのに必要な権限があるか -> YES or NO」みたいなのを検証してくれる機能がサービスとして提供され、API を経由して利用できます。
そんな機能紹介はさておき、記述言語が独自言語であるため、その言語についての紹介が半分の時間を占めていました。プログラム言語に詳しい開発者の方が出てきて、作った言語の思想を紹介していく姿は、学会にでも来たのか？という状況が味わえる良いセッションでした。あとで調べたんですが、発表者の方はプログラム言語に関するエキスパートで、POPL や PLDI などでソフトウェアの Synthesis や Verification を専門とするアカデミアの方だそうです。そんな方が AWS の Scientist として登壇されていたので幅広い分野の方々が AWS を支えているのを実感しました。
記述言語は Cedar という名前です。Rust で実装されていて、公式サイトに Playground があります。
詳細には解説されていませんでしたが、この言語自体に対する仕様の検証や Policy の同値性証明などの話もありました。世紀の発明、というほどではないんですが、ニーズや要件を満たす最小限の言語がドンと出て機能の中核を担っているの、アツいものがありますよね。
セッションは動画も公開されています。
The evolution of chaos engineering at Netflix
@s4ichi です。Netflix はセッションの種別に NFX という Prefix があるくらい特別視されているらしく、このセッションはそんな NFX 系の Chaos Engineering についての発表です。
Chaos Monkey で一部のリソースを勝手に停止するような文字通り "Chaos"な取り組みから、今は FIT（Failure injection Technology）を構築している様子についての発表でした。 microservices 上の様々な要素を観測するための分散トレーシング基盤やサービスメッシュが Netflix のインフラに構築されており、その上で Failure injection を柔軟に扱う仕組みがあるそうです。Chaos Monkey のようなランダム性のある取り組みは方向性は良かったのですが、計算資源単位ではなくドメインやアーキテクチャを考慮した失敗、というのをシミュレートしたいというモチベーション。特定のサービス間で耐障害性が低くなる部分があったことが原因の障害があり、シナリオベースで障害を注入できる必要があると学んだ、とのことでした。
Netflix のサービスはソフトウェアエンジニアなら誰でも FIT を使った障害の注入が可能になっています（専用コンソールがありそうな雰囲気でした）。Injection Point や Scope、Treatment（回復手段）にその Scenario を定義することができて、それをリアルタイムに実行できます。
具体的には、リクエストヘッダに対して（例では x-ntfx-fit-fail でした）コンテキストを付与することができます。その内容は、各サービスやその横にある Envoy が解釈して Failure injection をシミュレートするためのコンテキストになるそうです。 例えば、「サービスAからBに通信するクライアント側で Failure する。Canary リリースされたユーザーのグループCのみに適用。障害時はリクエストを Delay して失敗させる」ぐらいの粒度で指定が可能です。シナリオを用意しつつ、それを Canary や Production 環境と組み合わせてシミュレートできるため、非常に機能的でした。
「Chaos is dead, Long live...」言っていたのが印象的です。可観測性を上げ、FIT によって特定の箇所を狙って障害をエミュレートできるようにし、リリースの戦略と合わせてテストをできるようにすることで、カオスはたった一つの道具にすぎないと話していました。例えば当時からある Chaos Monkey はそれ自体は良いけど、今は殆ど使われていないそうです。
セッションの動画も公開されています。
Deep dive into Amazon Aurora and its innovations [Breakout Session]
@hilinker です。このセッションは、前半で Amazon Aurora の仕組みを解説しつつ、後半では直近リリースされた機能の紹介をするものでした。クックパッドでは Amazon Aurora を非常に多くのアプリケーションで採用しています。Aurora の細かい利点については AWS の公式ドキュメントに譲りますが、かなり様々な恩恵を受けています。
さて、特にここでは直近で発表された Aurora の新規機能のうち、特に以下２つについて触れておきたいと思います。
１つ目は、Amazon Aurora zero-ETL integration with Amazon Redshift です。
これは Aurora のデータをほとんどリアルタイムに Amazon Redshift 上に同期することができるというものです。 クックパッドではアプリケーションのデータベースとしては Aurora を利用し、分析などに用いる DWH として Amazon Redshift を採用しています。分析などの際には Aurora にあるアプリケーションのデータを Redshift 側にコピーして用いるのですが、このコピーは日次バッチなどを実行することで行っているケースがほとんどで、どうしてもデータの同期に時差が生じてしまいます。特に、最近は Redshift 上のデータを利用して組み上げたデータを元にして、リアルタイムにユーザーへコンテンツを表示したいという要求が社内で高まっていることもあり、Aurora、Redshift 間のデータの同期というのは悩みのタネでした。苦肉の策でバッチの実行間隔を狭めたりはしていましたが、あまりクールな解決とは言えませんでした。 そんな中で登場したこの新機能。いやぁ、待望と言わざるを得ないですね。これが入ると上述したような悩みのタネが一気に解決されます。 ただ、まだプレビュー版なのと、おそらく Aurora MySQL v3 からしか利用できないっぽいので、社内にある Aurora クラスタたちを v2 から v3 に上げていかなければならなそうなのはかなり大変かも。
２つ目は、Fully Managed Blue/Green Deployments です。
これは、Aurora クラスタのバージョン更新作業などのメンテナンス時に、Blue/Green デプロイメントを AWS 側の用意してくれたスキームで実施できるというものです。これは re:Invent の keynote とかで発表されたわけではなく、初日ぐらいにさらっとニュースが出ただけなのですが、マジで待望の機能でした。
軽く説明すると、Aurora にはエンジンバージョンがあります。で、バージョンがあるということは当然 EOL もあり、EOL までにアップグレードをかけなければならないのですが、このアップグレードの際にどうしても DB にダウンタイムが発生してしまいます。in-place upgrade というボタンをポチッとするだけで上げられる方法を使うとアップグレード自体は簡単にできるんですが、read も write も平気で10分以上止まるので認証サーバーなどのクリティカルな DB では採用できません。
では、そいつらどうやってアップグレードするかというと、もう１個クラスタを用意してそっちにデータをレプリケーションしつつ、アプリケーションからアクセスする writer をえいやで切り替える方法を取ります。この方法だとアプリケーションから接続するエンドポイントを切り替えるだけなので、まず read のダウンタイムは発生せず、かつ write のダウンタイムも数分で済みます。
じゃあ全部レプリケーション方式でやればいいじゃん！と思うかもしれませんが、このレプリケーション方式、マジで準備が面倒くさいんですよね。いや、本当に作業と確認しなきゃいけない項目が多すぎて時間とメンタルが溶けます。
ということでここらへんの面倒な準備を AWS 側でいい感じにやってくれて、ぽちぽちすると切り替えができるようにしてくれる（らしい）のがこの Blue/Green Deployment 機能になります。早口でいっぱい喋っちゃうぐらいには嬉しい。
Build your first project with Amazon CodeCatalyst [Workshop]
@hilinker です。今回発表された新サービスの１つである Amazon CodeCatalyst を触ってきました。最初は、「CI/CD をいい感じにしてくれるぐらいかな〜」と思っていたらそれだけではなく、なんか開発に必要なサービス全部入ってますみたいな超巨大サービスでした。
まず、Git レポジトリの機能があります。そして、当然 issue/PR が作成できます。この時点で結構面白いんですが、さらにファイルを Cloud9 で開けて当然コードの編集ができます。レポジトリ内に manifest ファイルを定義するだけで PR の CI や CD の workflow を CodePipeline 上に作成できます。当然、実行や結果の確認、ログ出力なども CodeCatalyst 上でできます。さらに CloudFormation との連携も提供されているのでインフラ管理もお手のもの……
未だかつてなくオールインワンのサービスで、来るところまで来たなという感じがして笑っていました。難しいこと考えずにとりあえず AWS に乗っかれば大丈夫というのはだいぶ面白いですね。
ただ、こんだけオールインワンでやっていながら結構他からの移植性みたいなのは気にしていて、たとえば IDE で言えば Cloud9 だけでなく普通に VSCode や IntelliJ も使えたり、GitHub をレポジトリソースにできたり、Jenkins などと連携できたりと部分的に既存のものを使えるようにしているのは割と気を遣っているなという印象でした。
個人的にちょっと面白かったのは、CodeCatalyst のアカウントは AWS アカウント（やその中のユーザー）とは別のものということですかね。１人は１つの AWS Builder アカウントを持っており、それが複数の AWS アカウントと結びつくという関係らしいです。
[NEW LAUNCH!] Provision and scale OpenSearch resources with serverless [Breakout Session]
@naoki_shigehisa です。このセッションは新機能の OpenSearch Serverless についての Breakout session でした。名前の通りですが、 OpenSearch Service のServerless モードがプレビューとしてリリースされたという内容です。
クックパッドの検索では主にsolrが使われていますが、 OpenSearch Service もどこかで活用できないかなと思っていたところ keynote で Serverless モードが発表され、興味津々でセッションを聞きにいきました。
驚いたのは Serveless モードでサポートしている auto scaling の機能を実現するための構成が、クックパッドの solr を使った検索システムの構成とかなり似ていたことです。
具体的には indexing 用の unit と search 用の unit が別に存在し、indexing 用の unit は index を作成して s3 に保存し、 search 用の unit は s3 に保存された index を使って起動するという構成です。時代がクックパッドに追いつきましたね。 現状ちょっと値段が高かったのですぐに活用するのは難しいかもしれませんが、せっかくなのでどこかで試しに使ってみたいなと思っています。
こちらのセッションは録画も公開されていたので、リンクを貼っておきます。
Improve search relevance with ML in Amazon OpenSearch Service [Workshop]
@naoki_shigehisa です。このセッションは SageMaker と OpenSearch Service を使って、単語の embedding を使ったテキスト検索を実現する workshop でした。
SageMaker 内で起動した notebook から OpenSearch へ embedding を含めたドキュメントを登録しておき、実際に検索する時にはSageMaker を使って作成したエンドポイントに対して検索クエリを投げて取得した embedding を使って OpenSearch に向けて検索リクエストを投げる形式で実装を行いました。これによって、単語の完全一致ではなくある程度意味を考慮してドキュメントの検索を行うことができます。
workshop用のコードの大半は予め用意されていてほとんど notebook 上でコードを実行するだけではありましたが、実装に必要な作業を大まかに把握できました。
機械学習の用途としては割とありがちなものだなと思いましたが、ほとんどの作業が SageMaker 内で起動した notebook 上で済むのはとても便利だなと感じました。モデルのデプロイやエンドポイントの作成まで notebook 上でコードを実行しているだけで完了するのは嬉しいですね。ぜひ活用してみたいです。
AWS GameDay: The New Frontier
id:sora_hです。先に述べたようなインタラクティブでアーカイブがないセッションとして、今年もGameDay に参加してきました (月曜午後の回)。当然、ランダムなチーム構成を希望して現地にいる他の知らない参加者とチームを組んで挑戦します。
最初に結果だけ書いておくと、2 度目の優勝を遂げて 2019年ぶりに Keynote の特等席を得たりしていました。
Sitting with a row of #AWSGameDay champions awaiting the start of @Werner keynote this morning. Congratulations to all of you, team pictures coming soon! #reInvent2022pic.twitter.com/2SnTZlr5LS
— Unicorn_Rentals (@unicorn_rentals) 2022年12月2日
今年、というか近年の GameDay は他イベントでの再利用など横展開がしやすいようにするためか、初期の競技性があるもの — 全てをデプロイしてそれをちゃんと動かし続けてポイントを得る、ではなくクエストでポイントを稼いでいく形式、実質的に AWS コンソール操作 RTA レースみたいになっているのはちょっと残念と言えます。今回も多分に漏れずその傾向で、難易度が高いクエストから処理していけば上位にいけるので、悲しいところです。
いちおう Learning Opportunity の一環としてのゲームであるため、他のメンバーのサポートなどに回ったりしています。他の会社どころか他の国や出身の人達と同じ目的に対して頑張るという意味では貴重な機会なので、ここはたいへん楽しいところで、そしてたいへん運ゲーなところですね。
また頻繁に上位にいるせいで PM に顔を覚えられていて、またお前か…のような反応を得つつ公式からツイートもされる始末です。うかつな結果を残すわけにはいかないので、引き続き精進しようと思います。
思い出
参加メンバーで会期後にグランドキャニオン含むツアーに弾丸参加したときの写真です。（id:sora_hは Re:ステージ! のライブに行くために一足早く帰ったため、5人での集合写真が存在しませんでした）
さいごに
クックパッドでは AWS re:Invent の参加を通して、実際のサービス・基盤開発に活かせることを発見したり、より効率よく AWS を利用できないか研鑽する取り組みを続けています。こうしたブログでの発信に留まらない発見や知見更新のチャンスが社内に溢れているためです。
クックパッドには経験年数問わず、熱量のあるエンジニアがこうしたカンファレンスに参加できる環境があります。興味を持っていただけた方は下記のリンクより採用情報を参考にしてみてください。