Infrastructure as Code: Docker Compose による金融生態系のデプロイ

みなさん、こんにちは！👋 前回の投稿では My Broker B3 の概説をお伝えしました。今日は「バンザイ」を開き、この生態系を支える基盤となるインフラについて深掘りしましょう。 マイクロサービスシステムにおいて、データベース、メッセージブローカー、監視ツールをそれぞれ手動で構成するのは、生産性の NIGHTMARE（悪夢）です。そのため、私は Docker Compose を使い、高度に複雑な分散システムの要件を再現するローカル環境を作成しました。 このプロジェクトにおける中心的な設計決定は「ドメイン別データ分離」でした。単一のモノリシックなデータベースではなく、各マイクロサービスに独立したインスタンスや論理的なベースを設けました： Relational Persistence (SQL): 証券取引（Brokerage）ドメイン（Identity, Wallet, Order, Asset）には MySQL 8.0、B3 Core には PostgreSQL 15 を使用します。これによりドメインの解耦が可能になり、例えば注文データベースの障害が Identity サービスに影響を与えないようにします。 Cache Layer (Redis): マーケットデータおよびウォレットサービスのために、個別の軽量 Redis (Alpine) インスタンスを実装し、速度が極めて重要な場面でもサブミリ秒の遅延を保証しました。 NoSQL (MongoDB): プライス履歴 (Ticks) やレポートなどの構造化されていないデータを保存するための中央集型のインスタンスを配置し、高いスキーマの柔軟性を確保します。 📡 メッセージング：システムの骨格 docker-compose.yml ファイルは、異なる目的を果たす 2 つのメッセージング巨人をオーケストラします： Apache Kafka (KRaft): 最新の KRaft モード（Zookeeper の不要化）で構成され、ローカル開発においてコンテナを軽量化・安定化しました。内部イベントの高負荷を処理します。 RabbitMQ: B3 シミュレーターとの間の通信のブリッジとして機能し、システム間の完全な解耦を保証します。 📊 デイ 1 からの観測可能性 管理できることはまず測定できます。そのため、私は Prometheus と Grafana をインフラコアに直接組み込みました。マイクロサービスがデプロイされる 즉시、メトリクスをリアルタイムダッシュボードで確認できるようエクスポート可能です。 プロフェッショナルなプロジェクトにおける重要な詳細はシークレット管理と設定です。私の docker-compose.yml においては、ハードコーディングされるパスワードとポートを避けるために環境変数を使用しました。 すべての機密設定は .env ファイルに隔離されており（Git で無視）、.env.example ファイルはテンプレートとして提供されています。これは、認証情報がソースコードに曝露されないことを確保するというセキュリティのベストプラクティスを示しています。 # 環境変数を使った docker-compose の一部 broker-identity-db: image: mysql:8.0 environment: MYSQL_DATABASE: ${BROKER_IDENTITY_DB_NAME} MYSQL_USER: ${BROKER_DB_USER} MYSQL_PASSWORD: ${BROKER_DB_PASS} インフラが自動化されたので、すべての 14 コンテナを起動するには単一のコマンドで十分です： docker-compose up -d この標準化により、プロジェクトに協力するすべての人が同じ開発環境を得られ、古典的な「私の机器では動く」問題を解消します。 次の投稿では、私が作成した最初のマイクロサービスについてお話しします。このサービスは外部の Brappi API と統合し、MongoDB にデータを保存し、リアルタイムの価格更新を Kafka トピックにパブリッシュします。

Hello, everyone! 👋 In my previous post, I presented an overview of My Broker B3. Today, let's "open the hood" and talk about the foundation that supports this entire ecosystem: the infrastructure. For a microservices system, manually configuring each database, message broker, and monitoring tool would be a productivity nightmare. That’s why I used Docker Compose to create a local environment that replicates the needs of a highly complex distributed system. A central design decision for this project was data isolation by domain. Instead of a single monolithic database, each microservice has its own instance or logical base: Relational Persistence (SQL): I use MySQL 8.0 for the Brokerage domains (Identity, Wallet, Order, and Asset) and PostgreSQL 15 for the B3 Core. This ensures domain decoupling—for instance, a failure in the order database won't affect the identity service. Cache Layer (Redis): I implemented isolated, lightweight Redis (Alpine) instances for market data and wallet services, guaranteeing sub-millisecond latency where speed is critical. NoSQL (MongoDB): A centralized instance for storing unstructured data, such as price history (Ticks) and reports, allowing for high schema flexibility. 📡 Messaging: The System Backbone The docker-compose.yml file orchestrates two messaging giants for different purposes: Apache Kafka (KRaft): Configured in the modern KRaft mode (eliminating the need for Zookeeper), which makes the container lightweight and stable for local development. It handles the high volume of internal events. RabbitMQ: Acts as our communication bridge between the Broker and the B3 simulator, ensuring complete decoupling between the systems. 📊 Observability from "Day 1" You can't manage what you don't measure. That’s why I included Prometheus and Grafana directly into the core infrastructure. As soon as a microservice is deployed, it can immediately export metrics to be viewed in real-time dashboards. A crucial detail for any professional project is secrets management and configuration. In my docker-compose.yml, I used environment variables to avoid hardcoding passwords and ports. All sensitive configurations are isolated in a .env file (ignored by Git), while an .env.example file is provided as a template. This demonstrates a security best practice by ensuring that credentials are never exposed in the source code. # Excerpt from docker-compose using environment variables. broker-identity-db: image: mysql:8.0 environment: MYSQL_DATABASE: ${BROKER_IDENTITY_DB_NAME} MYSQL_USER: ${BROKER_DB_USER} MYSQL_PASSWORD: ${BROKER_DB_PASS} With the infrastructure automated, a single command is enough to spin up all 14 containers: docker-compose up -d This standardization ensures that the development environment is identical for anyone collaborating on the project, eliminating the classic "it works on my machine" problem. In the next post, we’ll talk about the first microservice I created. This service integrates with the external Brappi API, stores data in MongoDB, and publishes real-time price updates to a Kafka topic.