はじめに
インフラ/バックエンド担当の森井です。 2023年6月22、23日に開催されたAWS Dev Day 2023 Tokyoに参加してきました。
今月弊社に入社した川島さんも一緒に参加してきたので、「印象に残ったセッション」の章では川島さんにも執筆してもらいました。ぜひ御覧ください。
AWS Dev Dayについて
AWS Dev Dayは「AWS国内イベント最大の開発者向けテクニカルカンファレンス」です。
ちなみに、有名なAWS Summit Tokyoは、「日本最大の "AWS を学ぶイベント"」と紹介されます。 比較すると、DevDayはより”開発”に重きをおいたカンファレンスという位置づけであることがわかります。
会場の雰囲気
今年のDevDayはベルサール渋谷ガーデンで開催されました。 渋谷駅から徒歩10分ほどの立地です。 都内在住の私としては参加しやすく助かります。
会場内には主にセッション会場5つ、スポンサーブース、休憩所が設置されていました。 AWS Summit Tokyoではどのセッションも混雑していて、遅めに入場すると立ち見になってしまうような状況でしたが、DevDayは座席利用率8割といった感じで快適に活動できました。
お昼になるとお弁当の販売がありました。 1つ600円とリーズナブルで味もよく、とても満足でした。（2日間ともこちらで購入しました）
印象に残ったセッション
特に印象に残ったセッションについて紹介します。
『質とスピード』特別編 〜 現代のソフトウェア開発にキャッチアップしていくヒント〜
個人的に伝説の公演だと思っている「質とスピード」が生で聞けました。
内容自体は知っているものでしたが、聞く度に気づくことがあり面白いです。
今回印象に残ったのは、スピードが質を向上させるパターンがあることです。
「質を向上させればスピードがあがるよ」という話はソフトウェア設計の話には必ずと行って良いほど登場する文句ですが、その逆はあまりスポットが当たりにくいのですよね。
スピードが出ないということはつまり、パッチワーク的なコードを書いていたり、リファクタリングの時間が取れていないということで、これはエンジニア自身の設計スキルが上がらないということでもあります。
こういった状況の原因を突き詰めていくと結局ビジネスの話になってきたりするので、技術だけに閉じずに改善する必要性を実感しました。
実践エッジユースケース
少し前に、Wasmer社から「The Cloud is dead, long live the Cloud! Announcing Wasmer Edge」という強めの発表があり、丁度エッジコンピューティングに興味がでてきていましたし、いざというときに使用できる設計パターンの引き出しにエッジも入れておきたいなと。
発表者の@yusukebeさんは個人で開発したエッジ用フレームワークが評価されCloudflare社に所属することになったすごい方で、発表を楽しみにしていました。
オリジンがある場合のエッジユースケースとして、下記が紹介されていました。
- レスポンスヘッダの追加/削除
- CORS
- 認証
- ETagの追加
- リダイレクト
- オリジンの振り分け
- キャッシュ
- デバイス別のキャッシュ
- HTMLタグの置換
- ホットリンク禁止
- 動的コンテンツのキャッシュ
等々。バックエンド側のリバースプロキシで対応できるものもありますが、やはりキャッシュ周りはエッジ側で対応するメリットも大きそうです。
とはいえキャッシュは複雑性を持ち込んで処理が負いづらくなる側面もあるので、あれもこれもやるというより、ボトルネックとなる部分にピンポイントで持ち込むのが良いと思います。
また、バックエンド側にリバースプロキシを用意しない場合は、エッジ側に細かな制御を寄せるとバックエンドのコードはビジネスロジックに集中できるのも良いですね。
せっかくなので、こちらの記事を参考にHonoを動かしてみました。
Hono + Cloudflare Workers で REST API を作ってみよう
執筆時点で最新のwrangler@3.1.1を入れたらエラーが発生して使えず、wrangler@2.0.27を変更して事なきを得ました。（同様のエラー報告）
エラーに遭遇してしまったのでCloudflare Workers登録からHelloWorldするまで1時間程度かかってしまいましたが、これがなければ30分もかからないと思います。興味のある方はぜひ触ってみてください。
HonoはWeb Standard APIに準拠しているそうで、これによりどのプラットフォームでもほとんど同じコードが動くようです。フロントエンド技術が苦手な私でも普通に運用していけそうだなと思いました。
この発表では触れられていなかった、オリジンがないパターンのエッジユースケースも含めて、今後も追っていきたいと思います。
失敗知識から学ぶ！クラウドアプリ設計で避けるべき事例とその対策
（このセクションは川島が書いています。）
物事を学ぶなら成功よりも失敗から学ぶことの方が多いと思うので失敗に関するセッションを1つ紹介したいと思います。
よくあるケースとして二つの失敗例が紹介されていました。
- 1万テナント×100Table用意した結果、全部で100万のDatabase Tableが作成されてしまったケース
- 3万クライアントから毎分ログ収集した結果、毎月11億のAmazon S3 PUT, COPY, POST, LIST リクエストが発生したケース
どちらもオンプレからクラウドに移行する時に、市場投入までの時間を短縮するためアプリ改修をできる限り行わないで実装しようとした結果発生した失敗例でした。 面白いと思ったのは短期的なスピードを選んだことが今になって大きな影響を及ぼしているとしても、その当時であればビジネス上必要であったかもしれないという観点です。
私はまだエンジニアの観点しか持っていないため上記のケースは純粋に失敗と考えましたが、ビジネスとしてここまで成長させたなら一概には失敗と言えないと仰っていて、ビジネス側の視点も理解するのが大事なのだなと思いました。
ただ強調されていたのは、設計判断のトレードオフを評価可能なメトリクスを定義・計測し、運用開始後に見直しできるようにする事が最も重要との事でした。
何をメトリクスとして取得すれば運用開始後に見直し出来るかという判断も多くの経験と知識が必要と思うので先輩に学びながら成長していきたいなと思いました。
おわりに
バックエンドとクラウド両方やっている私としては、どのセッションも興味のあるもので、2日間とても楽しめました。 一点心残りなのは、Game Dayに参加登録したものの、ログインすらできなかったことでしょうか。通常チームで取り組むところ今回はSoloでも参加できる形式になっていて、やってみたかったのですが... （セションを存分に楽しんだので良いのですけどね）
フェンリルは技術カンファレンスに積極的に参加しています。 最新の技術や知見を活用して、今後もプロダクトの品質を高めて行きたいです。
