目的・課題あってのリアーキテクチャ/Omiai-Findy-LT

Transcript

1. © Omiai, Inc. 1 目的・課題あってのリアーキテクチャ
2. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 Omiaiエンジニアチーム テックリード 渡邊 裕又 大学生時に、iOSアプリケーションを独学で開発・リリースまで に漕ぎ着ける 新卒として、ベンチャー広告代理店に入社後、サービス開発・ 運営に携わりフロントエンド ~ バックエンド ~ インフラのシステ ム全体の開発・保守に携わる その後、フリーランスとして、あらゆる規模のシステム開発に携 わり、フルスタックエンジニアとしての経験を5年ほど積み 2019年6月より株式会社Omiaiに入社、TL/EL就任。
3. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 リアーキテクチャが本当に必要なのか？ ライフスパンが長いプロダクトのシステムにはまず必要となる ただ、スケールペースによっては実は必要でないかもしれない そもそもライフスパンが短い、スケールペースが遅いプロダクトはシステム的 な課題が継続化することがほぼない (したとしても一過性 )
4. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 継続的な課題に対しては手段を打つ必要性がある ライフスパンが長い・スケールペースが早いプロダクトのシステムではいわゆ る技術負債の積み重ねによる課題が継続化しやすく、プロダクト的なリスク (例えば開発期間の延長・不具合・検証コスト増加 )が頻発する こうなった場合に初めてシステム的な改善の手段 (リアーキテクチャ・リプレイ ス等)の手段を打つことの検討の必要性が生じる
5. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 プロダクトの成長・継続に必要なものを奪うコト 「プロダクト成長・継続」に必要なものはヒトとカネ (あとほんの少しの情熱 ) 技術負債の積み重ねによる課題は確実にヒトの時間を奪い、カネを浪費させ る
6. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 課題の因子となる技術負債はシステム活動によって生まれる システム的に無理のある仕様 仕様の失敗 間違った技術選定 間違ったアーキテクチャ設計 間違ったデータ設計 未来的なシステム革新による設計の陳腐化 設計の失敗 依存関係が複雑化するような共通化 スコープを意識せず、影響範囲を拡大させるような実 装 実装の失敗 全ての発生を防ぎ切るのは少々困難。 あらゆるシステム活動は技術負債を生む要 因となりうる
7. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 リアーキテクチャ・リプレイス自体が負債を生む リアーキテクチャ・リプレイス自体が課題の解決をするどころか、新しい技術 負債による課題を生む可能性は否定できない だからこそ手段が確実に継続的に発生している課題 (要は重要度の高い )を潰 せるのかを評価する必要性がある
8. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 Omiaiの場合(実際に生まれた新しい課題) PHPで実装しているシステムを Javaにリ プレイス • 開発者体験が向上する型付き言語 へのリプレイスが目的 • 機能的な重要度はつけていない • プロダクト的に解決すべき課題の評 価をしていない 2015年次リアーキ プロダクト的にスケールが必要な機能のリ プレイスが完遂できておらず、 Java・PHP の両方のエンジニアが必要になり、開発コ ストのみが増加 当時から1万人規模を想定したデータ設計 が手付かず(当時でも数百万の累計ユー ザーが存在) 結果
9. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 Omiaiの場合(2024リアーキ : 課題の洗い出し) 具体例 何が起きていて(おり)、どのように要素を減退させているか？ Frontend Software 未(ヒト)プラットフォーム間での仕様差分が激しく、仕様把握・影響把握が困難であり、要件定義・検証の工数を増大させている また、(ヒト & カネ)複数のプラットフォームそれぞれで複数のエンジニアを採用する必要性があり、組織の拡大が困難 Backend Software 未(カネ)APIの粒度が大きく、フロントエンドが必要ではない情報までAPIレスポンスとしているため、データ効率性が悪化し、データ操作コスト を増大させている 途中(ヒト)一部の結合度を著しく増大させる共通クラスが存在し、修正をする際に影響把握の上での実装・検証工数を著しく増大させている 済(ヒト)異なるプログラムミング言語で実装されており、プロクラミング言語ごとに複数のエンジニアを採用する必要性があり、組織の拡大が困 難だった Infrastructure 途中(ヒト)自前でインフラメンテナンスが必要なコンピューティングサービスを利用しており、運用工数がかかり続けている Database 済(カネ&ヒト)領域が設計がなされておらず、領域が違うデータが一つのテーブルにて管理されているため、一つの領域に関わる開発をする 際に全く関係のない領域の開発・検証が必要なり、開発コスト・検証コストが著しく増大していた 済(カネ)初期のデータ設計の失敗により、数億テーブルのコア機能のデータ取得が効率できておらず、効率を上げるために札束を犠牲にして いた Software, Infrastructure, Databaseのそれぞれで、継続的な課題と原因となる技術負債が 存在していた (する)
10. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 Omiaiの場合(2024リアーキ : 解決すべき課題の決定) 具体例 なぜそれをやらなければならなかったのか？ Backend Software 拡張期に向けて、プロダクトの既存機能のブラッシュアップ・新機能の追加が求められることが容易に想像でき、 システム機能の修正・追加させる際に影響範囲を増加させ、 開発コスト・検証コストを増大させる 状態を解消するため 時間がかかる組織の拡大・組織文化の構築をより早めるため、 組織拡張を遅らせる要因を取り除くため Infrastructure ヒト・カネを拡張期の実施する案件に集中させるため、定常的にかかるヒトを使う運用を解消するため Database (カネ&ヒト)影響範囲を拡大させ、ヒトとカネをコア機能の追加・修正に集中できなくなるような状態を解消しなければならなかった (カネ)札束で効率を上げるような状態を解消し、カネをより、コア機能の追加・修正に集中させるため リアーキでは Backend Software・Infrastructure・Databaseに特化して解消
11. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 どう解決したか - 依存関係の分解 ユースケースからデータモデリングをするのではなく、 Omiaiが提供している 機能の概念において存在しなければいけない 5W1Hベースでモデリング・ドメ イン分解を実施 機能とデータ・データとデータの相互依存の解消により、仕様変更による影響 範囲の拡大を防ぎ、一意性・再利用性のあるデータが保持できるように
12. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 どう解決したか - データ退避・インフラの最適化 12年間の保有データが存在し、パフォーマンス劣化が激しかったので、アク ティブユーザーに必要でないデータをバックオフィス用データサーバーに退避 またIaaSで提供していたデータサーバーをマネージドサービスに変更 ユーザーにとって必要な保有データが半分程度になり、マネージドサービス の移行が容易に・データ操作のパフォーマンスが著しく改善 データサーバーをマネージドサービスかしたことにより運用コストが実質的に 0 に
13. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 どう解決したか - 安全なデータ移行 Omiaiでは並行稼働形式でのリプレースを採用し、切り替え Moduleでリリースを実施し、不 具合が出たものも、即時切り替えにより、不具合検知から、 1時間以内には解決 切り替え後にプログラム修正・データ不整合の解消し、再リリース Backend Software (旧)Databa se Frontend Software (新)Databa se (旧)Module (新)Module 切り替え Module
14. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 結果(課題解決でできたのか？) 結果 Database 影響範囲を拡大させ、ヒトとカネをコア機能の追加・修正に集中できなくなるような状態を解消しなければならなかった → 影響範囲がドメインで区切られるようになり、特定が容易に → テーブルの再設計により、今後予定されている新機能の拡張が可能に 札束で効率を上げるような状態を解消し、カネをより、コア機能の追加・修正に集中させるため → テーブルの再設計により、データの無駄が省かれ、操作パフォーマンスが向上 → データ周りのインフラコストがおおよそ半分程度に (年間5000万程度に)
15. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 今後解決するべき課題とその対応 フロントエンド側でFlutterの導入を実施。 これにより、フロントエンドチーム構築のコストの低減・お よびにプラットフォーム間の仕様差分による検証コスト・開 発コストの低減 複数プラットフォーム対応のプロダクト特有の 開発コスト増 より安全で効率的なインフラ運用を目指し、優先度をつ け、インフラ構成の刷新(マネージドサービス ・PaaS・SaaSの導入) レガシー(IaaS)インフラによる運用コスト増 相次ぐ仕様の変更につき、必要以上にデータを取得して おり、パフォーマンスを劣化されているAPIを改修し、影響 範囲の拡大による開発コスト・リスク発生確立を低減させ る 影響範囲が必要以上に拡大している API クイック且つ高品質なサービス提供を目指し、CI/CDの拡 張とQA自動化によるリードタイム短縮、生産性向上、品 質向上の実施 継続的な外部品質の担保ができていない
16. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 まとめ システムはあくまで目的を達成するための手段である 手段で何を達成するのか、それが何をもたらすのかを考慮せずに、手段を振るうことはプラス どころかマイナスにもなりうる 当たり前のことだけど、人はそれをよく忘れて手段に固執してしまう Omiaiでは本質的なコトを重視し、手段を考えたことで、それなりの成果を得ることができた話