ファイル転送システムのマイクロサービスアーキテクチャ

ファイル転送向けのマイクロサービスアーキテクチャは、システムを専門化されたサービスに分解する。アップロード担当、メタデータ担当、通知担当、ウイルス検査担当といった具合だ。各サービスは独立してスケールし、独立して障害を起こし、チームが価値ありと判断したときに別の言語で書き直せる。利点は運用の柔軟性と明確なオーナーシップ。コストは分散システムの複雑さ、ネットワークオーバーヘッド、そして堅実な可観測性の必要性だ。経済産業省（METI）のクラウドセキュリティガイドラインが示す多層防御の観点からも、サービス間のmTLSと認可ポリシーは見落とせない。ここでは実用的なサービス分解と各部品の連携方法を解説する。

意味のあるサービス境界

すべての機能が独自のサービスを持つ必要はない。ファイル転送プラットフォームの合理的な分解：Upload Service（署名付きURL生成、マルチパート調整）、Metadata Service（PostgreSQL内の転送レコード、共有可能リンク生成）、Notification Service（SendGridまたはPostmark経由のメール、Webhook）、Scanning Service（マルウェアチェックのClamAVまたは商用AV）、Billing Service（Stripe統合）、そしてFrontend API Gateway（Kong、Traefik、またはAWS API Gateway）。6〜8のサービスが一般的にスイートスポットになる：独立したスケーリングのための十分な分離を持ちながら、リクエストをトレースするのが考古学になるほど多くない。

ステートレスなUploadサービス

Uploadサービスはステートレスで水平スケーラブルであるべきだ。その役割は署名付きURL生成、マルチパートアップロードセッションの調整、認証トークンの検証だ。すべての状態はキャッシュ（Redis）またはデータベース（PostgreSQL、DynamoDB）に存在し、ローカルプロセスメモリには一切持たない。これにより任意のインスタンスが任意のリクエストを処理でき、ブルー/グリーンデプロイとオートスケーリングが簡単になる。CPUまたはリクエストレートでスケーリングするKubernetesのHorizontal Pod Autoscalerがトラフィックスパイクを処理する。アップロード初期化のp99レイテンシは100ms以下を目標に。実際のバイトはクライアントからオブジェクトストレージへ直接転送され、このサービスを通過しない。

非同期処理のメッセージキュー

ウイルス検査、サムネイル生成、Webhook配信、メール送信は非同期処理であり、アップロード完了をブロックすべきではない。メッセージキューを使う：シンプルさとコストのAWS SQS、高スループットとリプレイのApache Kafka、柔軟なルーティングのRabbitMQ、またはGCP上ならGoogle Pub/Sub。アップロードが完了すると、Uploadサービスは「transfer.created」イベントを公開する。サブスクライバーがそれを取得する：Scanning ServiceがClamAVを実行し、Notification ServiceがメールとWebhookを送り、Webhook ServiceがエンドポイントにPOSTする。各サブスクライバーは指数バックオフで失敗時に再試行し、毒メッセージのデッドレターキューを持つ。

イベントスキーマとコントラクトテスト

イベントスキーマを合意してバージョン管理する。JSON SchemaやAvroが機能する。Protobuf経由のgRPCは厳密に型付けされたコントラクトで人気がある。{"type": "transfer.created", "version": "1.0", "id": "uuid", "sizeBytes": 5242880000, "createdAt": "2026-11-20T12:00:00Z"}のようなイベントは、新フィールドが追加的である限り進化が容易だ。破壊的な変更は移行期間中に両バージョンをサポートしながら「transfer.created v2.0」に移行する。Pactのようなコントラクトテストツールは本番ではなくCI環境でスキーマのドリフトを早期に発見する。

メタデータストレージの選択

PostgreSQLはほとんどのファイル転送メタデータのワークロードをうまく処理する：転送、ユーザー、共有、監査ログ、請求レコード。テーブルが100GBを超えたらcreated_atでパーティション分割してクエリを高速に保つ。高スループットには、複合キー（user_id、created_at）のDynamoDBが予測可能なレイテンシで数百万レコードにスケールする。読み取りが多いワークロードはリードレプリカまたはDBの前にインメモリキャッシュ（Redis、Memcached）を置くことで恩恵を受ける。転送メタデータはS3のファイルバイトと比べて極めて小さい（レコードあたり数KB）ため、適切なインデックスを持つ控えめなPostgreSQLインスタンスでも数十億件のレコードを保持できる。

サービス間通信

gRPCとProtobufは高速で型安全であり、高RPSの内部APIに適している。OpenAPI仕様のRESTはシンプルでcurlでデバッグできる。IstioやLinkerdのサービスメッシュはサービス間にmTLSを追加し、カナリーデプロイのためのトラフィックシフティングと、コード変更なしの自動リトライを提供する。ファイル転送システムでは多くの内部コールが低RPSの調整なので、RESTと小さなクライアントライブラリで通常は十分だ。UploadサービスからMetadataサービスへのルックアップはアップロード初期化のたびに発生するため、JSON over HTTPと比べた5〜10倍の高速化が意味を持つホットパスにはgRPCを使う。

サービスをまたいだ認証と認可

各サービスは呼び出し元が誰かを知る必要がある。Auth Service（Auth0、Keycloak、またはカスタム）が発行するJWTがリクエストチェーンを伝播する。各サービス境界でJWT署名を検証する。検証なしに主張を信頼しない。ユーザーコンテキストのないサービス間コールには、SPIFFE/SPIREを通じたサービスアイデンティティを使ったmTLSが強力なアイデンティティを提供する。OPA（Open Policy Agent）サイドカーが認可ポリシーを評価する：「ユーザーXは転送Yを読めるか？」を単一のポリシークエリとして。OPAにポリシーを集中させることは、すべてのサービスに「if user.id == transfer.owner_id」チェックを散在させるより優れている。

可観測性：ログ、メトリクス、トレース

可観測性がなければ、マイクロサービスは不透明なブラックボックスに退化する。OpenTelemetryのインストルメンテーションはトレース、メトリクス、ログをJaeger、Tempo、Datadogなどのバックエンドにエクスポートする。分散トレースはリクエスト全体を示す：フロントエンドがUploadサービスを呼び出し、MetadataサービスがPostgreSQLに問い合わせ、合計47msでDB12ms。PrometheusとGrafanaのメトリクスがサービスごとのRPS、エラーレート、レイテンシを追跡する。LoKiまたはElasticsearchでトレースIDで検索できるJSONの構造化ログ。エラーバジェットのバーン（SREスタイルのSLO）のアラートはユーザーが不満を言う前にリグレッションを検出する。

マイクロサービスが過剰になる場合

開発者1〜2名で月10万回の転送という小さなファイル転送サービスには、8つのマイクロサービスは不要だ。Go、Node.js、Railsの整理されたモノリスが2台の適度なVMでそのワークロードを処理し、数分でデプロイでき、サービスメッシュのデバッグではなく機能構築に時間を使える。マイクロサービスはエンジニア数が約20人以上のチーム規模、または異なるコンポーネントが大きく異なるスケーリング要件を持つ場合に効果を発揮する。HexaTransferのアーキテクチャは少数の専門化されたサービスと、S3互換ストレージとCDNへの大きな依存を組み合わせており、世界中で低レイテンシの10GB転送をサポートしながら運用の複雑さを管理可能に保っている。

https://hexatransfer.com — 無料、アカウント不要、最大10GB。