はじめに
コアテクの山口です。
フューチャー社内の有志メンバーでI/F設計ガイドラインを作成し、公開しました。
システム開発、特にエンタープライズ領域においてシステム間のデータ連携は避けて通れません。
本ガイドラインは、クラウドネイティブな環境におけるモダンなシステム間連携の設計指針を提供することを目指しています。
アピールポイント
連携方式の選定といった上流のアーキテクチャ設計から、ファイル形式や冪等性といった下流の詳細設計、そして結合テスト計画の指針まで網羅されたガイドラインになっています。
ピックアップコンテンツ
今回のガイドラインもボリュームがあるため、一部コンテンツを抜粋してご紹介します。
統合パターン
システム間連携の方式として代表的な4つの統合パターン（DB共有、RPC、メッセージング、ファイル転送）を比較し、それぞれのメリット・デメリットを解説しています。
- RPC（Web API連携）の結合度問題: モダンな印象のあるWeb API連携が、なぜシステム間の結合度を高め、将来的なリプレイスなどで課題となりやすいのかを具体的に解説
- メッセージング連携の勘所: 疎結合でリアルタイム性に優れる一方、順序保証や再送処理、データリカバリの複雑性が増すため、データ本体の連携ではなく「通知」としての利用を推奨
- ファイル転送の再評価: 大量データの一括処理やバッチ連携において、なぜファイル転送が堅牢で疎結合なアーキテクチャを実現しやすいのか
ファイル共有
クラウドならではの具体的なファイル共有の設計パターンに踏み込んでいます。
- Hub & Spoke vs Peer to Peer: データ連携ハブを導入する真の価値はどこにあるのか、ハブが持つべき責務を解説
- オブジェクトストレージの所有権: 連携で使うS3バケットは、配信側と集信側のどちらのアカウントで管理すべきか
連携ファイル仕様
ファイルレイアウトやデータ構造についても、実務で頻出する課題を取り上げています。
- 正規化 vs 非正規化: トランザクションの連携ファイルを設計する際に、マスタ情報を付与して非正規化すべきか、正規化された複数のファイルに分割すべきか
- バイナリ連携: 構造化データに加えて画像やPDFをどう連携するか
データ整合性
システム間のデータ整合性担保についても、頭を悩ませる課題を取り上げています。
- 差分連携の整合性担保: 差分連携で発生しうる「データ不整合」のリスクを指摘し、その対策としてチェックサム、定期的全件比較、定期的全件洗替の3つのパターンを比較・検討
- 冪等性・追い抜き制御: ジョブの多重実行を防ぐ追い抜き制御や、ファイル処理の順序性担保など、堅牢なデータ連携を実現するために不可欠な設計テーマについても具体的に解説
ガイドライン活動の感想
最後にこのガイドライン活動を通しての感想です。
ガイドライン活動を通じて得られるのは、対象のトピックへの知見だけではありませんでした。私も特定のトピックを検討していても、根底には適用箇所を選ばない、より普遍的な設計観点が存在しているという学びを得ました。
- 責務の明確化
- 疎結合・依存の最小化
- 整合性の担保
このような設計観点を養うためには、プロジェクトの枠を超えて集まった参加者同士で、フラットに議論が出来るガイドライン活動は理想的だと思います。
まだまだ参画のチャンスはありますので、構えずにご参加ください。
PullRequest募集中
ガイドライン活動に参画いただけない方も、お気づきの改善点がございましたら設計ガイドライン(GitHub) でのPRは大歓迎です！
※社内外問いません！
まとめ
本ガイドラインが目指したのは、システム間連携という複雑なテーマと日々格闘している方々に ご自身の考えと比較できる設計案 を提供することです。
ぜひ一度ご覧いただき、皆様のプロジェクトにお役立ていただければ幸いです。