アーキテクチャ Conference 2024 参加レポート
こんにちは。
株式会社ココナラのアプリ開発グループ、インフラ・SRE チームのクララとココナラ募集部 開発チームのカヤです！
今回は 11/26(火) に開発された「アーキテクチャ Conference 2024」に参加してきたので、レポートします。
アーキテクチャ Conference 2024 とは
本カンファレンスでは、ご登壇者の方々に今一度システムの基盤となるアーキテクチャの思考法や手法といった全体像から、他社が実践した具体的な構築事例といった部分像までをお話しいただくことで、アーキテクチャに対する考え方を学び直し、発想を広げられることを目指しています。
(公式ページから抜粋)
普段から活発にエンジニアリングに係るイベントを主催している Findy の Findy Tools が主催しています。
会場の雰囲気
入場すると、ブース出店の企業によるサービスの紹介や事例紹介、様々なユースケースでのアーキテクチャ図のボードなどが迎えてくれました。
ブースに立ち寄るといただけるシールを集めると大きなガラポンを回すことができ、エンジニアリングやアーキテクチャに関連するアイテムが当たる催しもありました。
オライリーが会場特典の割引で自社の書籍を販売しており、ちょうど読みたかったものが並んでいたので購入しました。
普段は書店や通販で購入するので初めて知りましたが、紙袋にもオライリーの定番である動物のイラストが描いてあります。可愛いです。
印象に残ったセッション
インフラ・SRE チーム クララの参加セッション
4 年で 17 倍に成長したエンジニア組織を支えるアーキテクチャの過去と未来
「これまで」と「これから」パートに分けて、「これまで」に行ってきた意思決定・施策とそのバックグラウンド、「これから」の方針とその希望についての発表でした。
中でも印象に残ったのは次の箇所でした。
- これまで
- 一般的にはアンチパターンである開発初期時点からのマイクロサービスアーキテクチャ採用の経緯とそれでもうまくいった要因の分析
- 大きくなってきたマイクロサービスへの対応
- これから
- 進化的アーキテクチャと適応度関数の導入
- アーキテクチャと Well-being
- マイクロサービスアーキテクチャによって実現される Well-being という観点は私の中になかったため、とても新鮮でした。
ZOZOTOWN のアーキテクチャ変遷と意思決定の歴史を ADR から振り返る
弊社でも最近少しずつADR(Architecture Decision Records)を書く取り組みが始まっています。
まさに私自身も2つ書いて、1つが採用、一つが提案中という状態だったため、前のめりで聴講しました。
技術選定・設計のタイミングで書くという印象を持っていたので、「ZOZOTOWNをリプレイスする」というかなり大きな決定に対してのADRがあり、驚きでした。
確かにArchitecture Decisionだな、と。
言語選定・技術選定の経緯が残っているのは、新しいメンバーが歴史について理解・把握する重要な手掛かりになるなと痛感しました。
自分のためにもチームのためにも、ADRは継続したいプラクティスです。
偶有的複雑性と戦うためのアーキテクチャとチームトポロジー
- 本質的複雑性と偶有的複雑性 (この概念の分かりやすい説明もログラスの資料の中にあります)
- アーキテクチャ
- チームトポロジー
という3つの要素を、パフォーマンス問題の改善にどう活かすか。という内容でした。
基本的なチーム・トポロジーの理解から出発して、問題解決のための独自のトポロジー進化のパターンを見つける。というエンジニアリングとして熟達した発表内容に圧倒されました。
また発表後半の「本質的複雑性を解消することで、偶有的複雑性も一緒に解消される」というのは大きな気づきでした。
ココナラ募集部 カヤの参加セッション
NewSQLを用いたDB分離のマルチテナントアーキテクチャー
多くのDB構成が存在するECプラットフォームを運営しており、運用面の課題解決と事業のスケールアップを考え、TiDBに移行してるお話を聞けました。
TiDBについては詳しくなかったため、概要やさまざまな勘所を学ぶ良い機会となりました。
- TiDB内の基礎構成が大きく4つのコンポーネントに分かれていること
- MySQL互換ではあるものの、オートインクリメントの仕組みなどの微妙に異なる部分があること
- MySQLからの移行に関してDMツールが有効であること
...などなど
このセッション以外でもTiDBの利用事例を紹介するセッションが多く、勢いを感じるプロダクトで目が離せないと感じました。もしかすると弊社でも利用する機会が来るかもしれないため、今後の動向を注視していきたいと思います。
「ソフトウェア開発の複雑さに立ち向かう」
書籍「現場で役立つシステム設計の原則～変更を楽で安全にするオブジェクト指向の実践技法」の著者としても知られる増田亨さんのセッションです。複雑で難しいソフトウェア設計・開発にどのように立ち向かうべきかについて、ご自身の豊富な知見から指針を示してくださいました。
このセッションで繰り返し語られたのが「事業視点」という言葉です。さまざまなエコシステムが乱立し、多くのパターンや原則が確立されつつも変化が激しいソフトウェア開発の世界では、技術面だけで解決策を見つけるのは難しいのが現実です。技術に加え、自分たちが展開する事業で何を競争優位とするべきかを考えることが重要です。
セッションの中では、「事業活動の当事者として設計する」ことが、複雑なソフトウェア設計において一つの判断軸になると主張されており、この指針を自分の中でも大切にしたいと感じました。
また、事業視点で設計に取り組むための4つのアプローチについても紹介されており、これらは常に目に届く場所に貼っておきたいほどの貴重なノウハウでした。
フロント・バック・エッジのどこで計算するか。フルスタック・プロダクトエンジニア的問題解決の事例
提供しているWebサービスの設計・実装について発表されたセッションでは、よくあるスタンダードな方法にとらわれず、サービスの特性を見直して固定観念に縛られない設計が非常に勉強になりました。
「他のコンピュータリソースを利用できないか？」というマインドセットを常に持つことが重要だというお話が特に印象的で、このマインドセットを活かすためにも、自分自身の知識の引き出しを増やすことが大切だと感じました。
具体的には、以下のような設計方針が紹介されました:
- バックエンドサーバーの分岐処理を利用する代わりに、エッジ（Cloudflare Worker）のスクリプトを使用し、バックエンドサーバーのリソース消費量を削減。
- キューイングの仕組みをフロントエンド側で実施し、バッチ・キューイング用の処理をバックエンドに持たせない。
- 検索にElasticSearchを利用せず、Web Workerを用いてフロントエンドで検索処理を行う。
別のリソースで管理することが増えるため、運用面でのコストが増えるという見方もあると感じました。しかし、それ以上に、リソース効率を最大化した柔軟な設計は、一つの「事業視点」として捉えることができ、非常に参考になりました。
さいごに
各企業のアーキテクチャ選定の背景や課題を知れるのは非常に貴重で、学びの多い楽しい時間でした。来年もまた開催を予定しているとのことなので楽しみです。
ココナラでもマイクロサービス化を始めとした既存アーキテクチャの改善を進めている真っ最中です。一緒にココナラのアーキテクチャを改善し、来年一緒にアーキテクチャカンファレンスに参加する仲間を募集してます！
Discussion