eBayのContinuous Deliveryチームはイベント中心のアプローチを使用して、障害に対するレジリエンスと、ビルドパイプラインの処理量増加に対処可能なスケーラビリティを備えた、継続的デリバリのためのオーケストレータを構築した。John Long、Nataraj Sundar両氏は、イベントソーシングの全般的メリットとアプリケーション開発に関して、氏らが認めたアドバンテージを２つのブログ記事で説明している。
eBayに勤務するLong氏とSundar氏は、イベントソーシングの背景にあるアイデアは多くの分野で長い間使われてきたものだ、と記している。例えば会計処理においては、すべての仕訳は不変な方法で記録され、現時点の貸借は関連する仕訳の総和によって計算される。間違いが生じた場合には、誤った仕訳を消すのではなく、新たに相殺仕訳を記録する。これを開発パイプラインを通じたコードの進捗状況と比較すれば、イベントソーシングは自然な流れであると言えるのだ。
イベントソーシングを実装したシステムであるEnterprise Continuous Delivery(ECD)は、プルリクエスト、ビルド、テスト、デプロイメントを通じてコードが移動し、多くの内部システムが使用するパイプラインを調整し、定義し、監視するオーケストレータだ。イベントソーシングを使用するECD内のコンポーネントであるPipeline Execution Service (PES)は、パイプラインを実行および追跡し、その状態をGitHubにレポートする目的で使用される。サービスはアクタモデルであるAkkaを使って、Scalaで記述されている。
イベントソーシングを用いることの一般的なメリットに加えて、Long氏とSundar氏は、PESでイベントソーシングを採用した３つの主要な理由を挙げている。
- 並行性。氏らのシステムは、パイプラインのさまざまな部分からイベントがほぼ同時に受信されるという、競合状態の問題を抱えていた。それぞれのイベントを直列的に処理すれば、並行性の問題はより簡単に解決できる。
- デバッグとトレーサビリティ。小チームで多数のパイプラインをサポートしているため、障害の理由をすばやく見つけて修復することは不可欠だ。
- 明確さと正確さ。オーケストレーションは企業にとって重要であり、非常に複雑なものなる可能性がある。高品質で理解の容易な、シンプルなコードベースが必要だ。そのためにはコードを受信情報の記録、最終モデルの算出、モデルの変化への対応という部分に分割することが有益である。
イベントソーシングを選択した最も大きな理由は、最後のポイント - 明確さと正確さだ。時間と状態に関わる相応に複雑なシステムであれば、イベントソーシングこそが選ぶべき道だ、とLong氏とSundar氏は主張する。適切に設計されたモデルを備え、プロセスのさまざまな部分が個別に処理されることで、理解の容易なプロセスが構築される。この実装をより詳細に見ると、4つのコンポーネントで構成されていることが分かる。これらのコンポーネントはそれぞれ理解や議論が容易で、変更やテストも簡単だ。
- 着信イベントを検証し、必要であれば関連する内部イベントの生成と格納を行う。
- 記録されたイベントを挿入順に処理し、それぞれのイベントに対してビューモデルを適切に更新する。
- 各イベント後のビューを永続化し、クエリ毎にすべてのイベントのロードと実行をしなくてもクエリを実行できるようにする。
- 状態の変化に対処して、モデル更新によって何をすべきかを決定する。その後、変更に関連する新たなアクタを起動して、アクションを実行する。
システムはこれまでに220万件を越えるランイベントを処理し、約20万回のランビューが発生している。実用的かつ直感的なソリューションの実装にはイベントソースアーキテクチャが不可欠だ、とLong氏とSundar氏は主張する。
この記事を評価
- 編集者評
- 編集長アクション