【ITニュース解説】Simply Order (Part 3) — Linking It All Together: Connecting Services and Watching Temporal in Action

この解説では、オンライン注文システム「Simply Order」の構築を進める第3部の記事内容を、システムエンジニアを目指す初心者の方にも分かりやすく説明する。Simply Orderは、大量の注文を効率的に処理し、障害が発生しても止まらずに動き続ける、堅牢で拡張性の高い分散システムを目指している。前回の記事では、注文処理の全体像を「Sagaワークフロー」という形でTemporalというツールを使って設計・実装した。今回は、そのワークフローを実行するために必要な、個々のサービス（注文、在庫、決済）の骨格を作り、それらを連携させて、実際に動かしてみる。現段階では、データは一時的にメモリ上に保存されるが、次のステップで永続的なデータベースを追加する予定である。

まず、システムを構成する三つのサービスについて説明する。

一つ目は「注文サービス（Order Service）」である。これはシステムへの入り口となり、顧客からの注文を受け付け、新しい注文を作成する役割を担う。注文サービスには、新しい注文を受け付けるための「注文作成」と、既存の注文の現在の状態を確認するための「注文取得」という二つの機能がある。新しい注文が作成されると、注文に関する情報は一時的に注文サービスのメモリ上に保存され、すぐにTemporalワークフローを開始する。このTemporalワークフローが、注文の処理全体を管理し、在庫確認や決済処理といった一連の手順をオーケストレーションする中心的な役割を果たす。

二つ目は「在庫サービス（Inventory Service）」である。このサービスは非常にシンプルで、注文に必要な商品の在庫を予約するリクエストを受け付ける。今回のデモンストレーションでは、あえて「注文した商品の数が3個を超えると在庫がない」という一時的な条件を設定している。これは、もし在庫が不足した場合に、注文処理全体をどのように元に戻すか（これを「補償処理」と呼ぶ）をTemporalワークフローが適切に実行することを示すためである。また、もし在庫サービス自体が一時的に停止してアクセスできなくなったとしても、前回の設定でTemporalワークフローのアクティビティ（ワークフロー内の個々の処理単位）に「リトライ（再試行）」の仕組みを組み込んでいるため、ワークフローはすぐに失敗せず、サービスが復旧するまで再試行を続ける。在庫サービスは、在庫予約を解除するための「予約解除」の機能も提供しており、これは前述の補償処理の際に利用される。

三つ目は「決済サービス（Payment Service）」である。在庫サービスと同様に、このサービスも決済の承認処理をシンプルなロジックで行う。今回のデモンストレーションでは、「注文金額が500未満であれば決済を承認し、500以上であれば決済を拒否する」という条件が設定されている。決済が拒否された場合（これもステータスコード209で示される）、在庫サービスと同様にTemporalワークフローの補償処理がトリガーされ、必要に応じてそれまでの処理が元に戻される。決済サービスも、決済を取り消す（返金する）ための「決済無効化」の機能を持っており、これも補償処理の一環として利用される。

これらのサービスとTemporalの各要素（Temporal ServerとTemporal UI）をまとめて動かすために、「Docker Compose」というツールが利用される。Docker Composeを使うと、複数の異なるサービスを一つのコマンドで簡単に起動・停止できる。これにより、開発環境の準備が非常に楽になる。アプリケーションを起動するには、プロジェクトの特定のディレクトリに移動し、「docker compose up」というコマンドを実行するだけで良い。Temporal UIは、ブラウザでアクセスできるインターフェースで、実行中のTemporalワークフローの進行状況や履歴を視覚的に確認できる、非常に便利なツールである。

実際にアプリケーションを動かして、最初の注文を作成してみよう。 まず、curlコマンドというツールを使って、注文サービスの「注文作成」機能にダミーの注文情報を送信する。これにより、新しい注文が作成される。注文作成直後の応答では、注文のステータスは「OPEN」（受付中）と表示される。しかし、少し時間をおいて「注文取得」機能で同じ注文のステータスを確認すると、「COMPLETED」（完了）に変わっていることが確認できる。この間に何が起こったのかを詳しく見るために、Temporal UIが活躍する。ブラウザでTemporal UI（通常はlocalhost:8080）にアクセスし、作成された注文IDに対応するワークフローを探してクリックすると、注文が作成されてから完了するまでの、全ての処理の流れ（タイムライン）がグラフィカルに表示される。ここでは、注文サービスがTemporalワークフローを開始し、そのワークフローが在庫サービスに在庫予約を依頼し、次に決済サービスに決済承認を依頼し、両方が成功した後に注文が完了する、という一連の流れを視覚的に追跡できる。

次に、サービスの一部が停止した場合にTemporalがどのように対応するかを見てみよう。 例えば、決済サービスを意図的に停止させるために、「docker compose stop payment-service」コマンドを実行する。この状態で、再び新しい注文を作成してみる。注文作成後の応答では、ステータスは「OPEN」と表示される。その後、注文取得機能でステータスを確認すると、「INVENTORY_RESERVED」（在庫予約済み）となっていることが分かる。これは、在庫サービスによる在庫予約までは成功したが、決済サービスが停止しているため、それ以降の決済処理が進んでいない状態を示している。この時、Temporalワークフローは止まってしまったわけではない。前回の設定で、Temporalのアクティビティには「リトライ」の設定が施されているため、決済サービスへの接続が失敗しても、Temporalは一定の間隔（今回のデモンストレーションでは、デバッグのために長い間隔に設定されている）で繰り返し再試行を続ける。Temporal UIでこのワークフローの状態を確認すると、「Running」（実行中）となっており、決済処理のアクティビティがエラーを検知しながらも再試行を続けている様子が確認できる。

ここで、停止していた決済サービスを再開させるために、「docker compose start payment-service」コマンドを実行する。サービスが復旧し、Temporalが次にリトライを試みたとき、今度は決済サービスへの接続が成功し、決済処理が再開される。再び注文取得機能でステータスを確認すると、今度は「COMPLETED」になっていることが確認できる。これもTemporal UIでタイムラインを見ると、決済サービスが停止していた期間は処理が中断していたが、サービスが再開された瞬間に処理が再開され、無事に完了に至った様子が視覚的に表示される。これは、Temporalが分散システムにおいて、サービスの一部に障害が発生しても、ワークフローの状態を確実に保持し、サービス復旧後に自動的に処理を再開できる、非常に高い回復力と堅牢性を持っていることを示している。

今回のセッションでは、各サービスを連携させ、Temporalというツールを使って実際に注文システムを動かし、ワークフローの追跡や、サービス障害からの回復がいかに容易であるかを具体的に確認した。Temporal UIは、複雑な分散システムの処理のタイムラインや、エラー発生時のリトライ状況などを完全に可視化し、システムの挙動を深く理解するのに役立つ。次のステップでは、この注文システムに永続的なデータ保存の仕組み（データベース）を追加し、システムの堅牢性をさらに高めていく予定である。