■ 1. 要件と開発方針
- 要件:
- ニアリアルタイムでのトランザクションデータ処理が必要
- トランザクション連携が事業の生命線であり可用性と回復性を高水準で実現することが求められる
- 主体処理と付帯処理の整理および非同期処理のフル活用が前提
- 複数の連携起点を1つの連携経路に集約し登録・更新・削除のデータライフサイクルを実現する
- 開発方針:
- 要件漏れが許されないためウォーターフォール型で開発
- 先行システムの仕様を可能な限り踏襲
- 開発手法の柔軟性を一定確保した上で進行
■ 2. システム特性
- 獲得を目指す5つの特性:
- 可用性
- 回復性
- 整合性
- ニアリアルタイム性
- 独立性
- これらは妥協なく獲得を目指しトレードオフが発生する場合は相談の上で調整する
■ 3. システムデザイン
- 初期構想から大きく外れることなく現在の構成に着地
- 外部結合テストやシナリオテストの段階で構成上の欠陥が顕在化し最適化を実施
- トラフィック量を意図的に増やした動作検証によって欠陥を発見
- 取引先との期待値調整と交渉を経て設計変更を実現
■ 4. 工夫
- PubSubのイベント発信基盤の活用:
- コアシステムのイベント発火をトリガーとして連携フローを構成
- サテライトシステム側がすべてのイベントを受信した上で連携対象を取捨選択
- コアシステムは自システムの事実の送信に専念しサテライトが追従する主従原則を採用
- PubSubによるシステム間の疎結合化により組織スケーラビリティも実現
- 経路選択と連携実行の分離:
- サテライトシステム内部で経路選択と連携実行を分離して処理
- ノイジーネイバー問題の解決とAPI連携実行側の責務分離を実現
- 経路選択で有効イベントを選別しA/B/Cといった経路へのデータルーティングを担う
- 連携実行側は事前条件チェックと連携処理および付帯処理の実行を担う
- Cloud Tasksのリトライとリクリエイト機構の活用:
- サテライトシステム内の処理はCloud Tasksを用いて逐次処理する構成を採用
- Cloud Tasksが呼び出すAPI処理は例外なく冪等性を担保する原則を設ける
- 冪等性担保によりリトライ処理の恩恵を受け自然回復可能な状態を実現
- 技術選択がシステム特性の獲得を容易にする代表例
- 冪等性担保と差分チェックによる最小限のリクエスト送信:
- 外部システムへのリクエストは連携の必要性を都度チェックし必要な場合のみ送信
- 前回リクエスト時のパラメータをログ保存し差分チェックを行う
- 不必要なリクエストを排除することでスループット低下とリソース過剰消費を抑制
- サテライトシステムのPull型データ取得:
- 連携に必要なデータはコアシステムへの参照APIで都度取得するPull型を採用
- Cloud Tasksパラメータでは参照のキー情報のみを受け渡す
- 常に最新データ状態で処理が実行される前提で処理を構成
■ 5. 発見
- システム特性はテクニックと戦略で決まる:
- テクニック: リトライ機構の整備やUpsertによる冪等性担保など即効性のある実装レベルの知識
- 戦略: システム構成やクラウドサービスの選択など実装以前の設計判断
- 戦略によってシステム特性の獲得容易性が規定されるためシステムアーキテクトは戦略にこだわる必要がある
- 連携で価値を生む系SaaSはコア/サテライト構成が最適:
- マルチテナントのコアシステムとシングルテナントのサテライトを分離する構成が有効
- コアの純度を守りつつサテライトで顧客要望に対応することで事業競合優位性を確保
- 非同期処理と結果整合性への習熟が技術の最適解選択の幅を広げた
- クラウドサービスをフル活用する時代:
- 2026年時点でクラウドサービスをフルで活用できる技術と思考が整った
- 非同期処理系を中心に従来より低コストかつ柔軟性と拡張性を持った開発が可能になった
- AIに代替されにくい領域:
- プログラマーの職はAIに置き換えられる一方で開発の責任を人が取って推進する領域は残存する
- 運用容易性や運用安全性の保証はAIには困難であり運用は点ではなく線で考える長い時間軸の世界
- 少なくとも10年単位ではすべてがAIに置き換えられることはないと考える