Posted inDevelopment

Dapr：マイクロサービス開発を劇的に楽にする「救世主」

Development tutorial - IT technology blog
Development tutorial - IT technology blog

マイクロサービスにおける「インフラ」という悩み

マイクロサービス開発は、得られるメリットよりも「頭の痛い問題」の方が多いと感じることはありませんか？基本的なタスクをこなすためだけに、コードに大量のSDKを詰め込むことに疲れていないでしょうか。サービスAからサービスBを呼び出す際にはmTLSやリトライメカニズムを考慮し、Redisにデータを保存したりKafkaでメッセージを送信したりするには、また別のライブラリを学習しなければなりません。その結果、本来のビジネスロジックが複雑なインフラロジックに埋もれてしまいます。

Dapr (Distributed Application Runtime) は、この混乱を整理するために誕生しました。これはアプリケーションと並走するSidecar（サイドカー）として機能します。セキュリティ、データベース接続、メッセージブローカーといった重い処理はすべて、シンプルなHTTP/gRPC標準を介してDaprが肩代わりしてくれます。

クイックスタート：5分で体験するDapr

まずはDapr CLIをインストールしましょう。これには30秒もかかりません。

# MacOS/Linux用のCLIをインストール
curl -fsSL https://raw.githubusercontent.com/dapr/cli/master/install/install.sh | /bin/bash

# ローカル環境の初期化（Dockerが必要）
dapr init

dapr init コマンドを実行すると、デフォルトのState StoreとしてRedisコンテナが用意されます。これで、複雑なRedis接続コードを書く代わりに、Daprサイドカーを起動してcurlコマンドを送るだけで済むようになります。

# ID 'myapp' でサイドカーを実行
dapr run --app-id myapp --dapr-http-port 3500

データベースに値を保存してみましょう：

curl -X POST http://localhost:3500/v1.0/state/statestore \
  -H "Content-Type: application/json" \
  -d '[{"key": "order_id", "value": "12345"}]'

データの取得も非常にシンプルです：

curl http://localhost:3500/v1.0/state/statestore/order_id

ここで重要なのは、アプリケーション側はRedisが何であるかを全く知る必要がないという点です。アプリケーションはただ localhost:3500 と通信するだけです。将来的にRedisからMongoDBやSQL Serverに変更したとしても、アプリケーションのコードは100%そのまま維持できます。

最も価値のある3つの機能

1. Service Invocation：IPアドレス不要のサービス呼び出し

通常、サービスAがサービスBを呼び出すには、IPアドレスやDNSを知る必要があります。Daprを使えば、必要なのは名前（App-ID）だけです。Daprがサービス発見（Service Discovery）と通信の暗号化（mTLS）を自動で行います。これにより、サービス間のAPI呼び出しに必要なボイラープレートコードを最大80%削減できます。

# 複雑なIPを直接呼び出す代わりに、サービスのIDで呼び出す
GET http://localhost:3500/v1.0/invoke/order-service/method/checkout

2. State Management：5分でデータベースを切り替え

これは特筆すべき機能です。DaprはKey-Valueストア全体を抽象化します。今日はコストを抑えるためにRedisを使い、明日上司からスケールのためにAWS DynamoDBへの移行を命じられたとします。その場合でも、DaprのYAML設定ファイルを1つ書き換えるだけで済みます。新しいSDKのインストールも、ロジックの修正も一切不要です。

3. Pub/Sub：超高速な非同期通信

サービス間のメッセージ送信がかつてないほど軽快になります。DaprにデータをPOSTすれば、Daprが自動的にKafkaやRabbitMQへプッシュします。メッセージを受け取るサービスは、Daprがデータを届けるためのHTTPエンドポイントを開放しておくだけでOKです。これにより、アプリケーションを特定のメッセージブローカーへの依存から完全に切り離すことができます。

Kubernetesへのデプロイ

Kubernetes (K8s) 上で、Daprは自動サイドカーインジェクション（Sidecar Injection）メカニズムによって真価を発揮します。デプロイメントファイルに数行の annotations を追加するだけです。

metadata:
  annotations:
    dapr.io/enabled: "true"
    dapr.io/app-id: "order-processor"
    dapr.io/app-port: "8080"

このファイルを適用すると、Dapr Control Planeが自動的にアプリケーションの隣で動くコンテナを「挿入」します。すべてのインバウンド・アウトバウンドトラフィックは、この「門番」によって制御・最適化されます。

実践アドバイス：見落としがちな重要ポイント

JSONデータの管理

DaprはJSONを介して通信するため、ペイロードのデバッグは日常茶飯事です。時間を節約するために、私はよく JSON Formatter を使ってDaprからのログを素早く整形しています。データ構造を明確に把握することで、ターミナルで生のログを読み続けるよりもはるかに早くロジックエラーを発見できます。

最初から分散トレーシングを有効にする

DaprはZipkinやJaegerを標準でサポートしています。設定を有効にするだけで、システム全体のトレース図をすぐに確認できます。数百のサービスが存在する大規模システムにおいて、この機能は推測に頼ることなく、数クリックで「ボトルネック」を特定するのに役立ちます。

レイテンシ（遅延）に関する注意点

どのようなサイドカーであっても、ネットワークに1つの「ホップ（跳ね返り）」を追加することになります。実際、Daprは各リクエストに約1〜2msの遅延を加えます。一般的なWebアプリケーションの99%において、この数値は得られるメリットに比べれば無視できるものです。ただし、マイクロ秒単位の低遅延が求められる金融システムなどを構築する場合は、最適化のためにgRPCの使用を検討してください。

まとめ

Daprは単なるツールではなく、開発者が複雑なインフラから解放されるための新しいアプローチです。もしKubernetes上でマイクロサービスを構築しているなら、次のプロジェクトにDaprを取り入れてみてください。システム管理が驚くほど楽になることを実感できるはずです。

Share:
Tags: