はじめに

本記事は、国立研究開発法人理化学研究所様の専用線・VPN接続/Nextflow 実行環境の導入に関する事例解説(Partner Interconnect 接続編)の続編です。

前回の記事では、Partner Interconnect の開通に至るまでの作業フローや、複数ベンダーが介在するプロジェクトならではの注意点を中心にご紹介しました。
今回はその続編として、実際に構築した構成の全体像にフォーカスし、

  • 石狩DC(北海道石狩市のデータセンター)を活用した構成
  • OCX(Open Connectivity eXchange)を介した Partner Interconnect 接続
  • 冗長化を考慮した閉域ネットワーク設計
  • Fluent Bit を用いたログ収集と Cloud Logging への連携
  • Cloud Monitoring を活用した監視設計

をご紹介します。機微な研究データを安全に搬送するための「閉域ネットワークの設計」と、閉域網ならではの工夫が求められた「ログ収集・監視の仕組み」を、当時の内容をまとめた紹介記事となります。

なお、本プロジェクト全体の導入事例については、以下のページでもご紹介しています。

プロジェクトの背景と要件

本プロジェクトは、理化学研究所 生命医科学研究センター 予測医学特別プロジェクト（研究責任者：桜田 一洋）の研究課題「AIを活用したデータ駆動型アトピー性皮膚炎研究」の一環として実施されました。
理化学研究所様では、研究で取り扱う機微なデータを国内のデータセンターから Google Cloud へ搬送し、クラウド上で解析を行う基盤の構築を進めていました。取り扱うデータの性質上、重要な要件は次の点でした。

アップロード時にデータがインターネットを経由しないこと。

データの搬送元となるアップロードサーバは、石狩DC(北海道)に設置されており、ここから東京リージョン(asia-northeast1)の Google Cloud 環境まで、エンドツーエンドで閉域のネットワークを構築する必要がありました。

また、閉域網の中に置かれたサーバは外部からのアクセス手段が限られるため、「遠隔地にあるサーバの状態をどのように把握し続けるか」という運用監視の課題も同時に解決する必要がありました。

全体構成

構築した構成の全体像は以下のとおりです。

ポイントは次の3点です。

  1. 石狩DCのアップロードサーバから Google Cloud までの経路は、OCX を介した Partner Interconnect によるインターネットを経由しないプライベート接続
  2. Google API へのアクセスは Private Service Connect(PSC)エンドポイント経由とし、名前解決も Cloud DNS で閉域内に完結
  3. アップロードサーバのログは Fluent Bit で Cloud Logging へ集約し、Cloud Monitoring で死活監視を実現

データのアップロードは、アップロードサーバから gcloud storage cp コマンドを利用し、PSC エンドポイント経由で Cloud Storage へ転送します。gcloud storage cp は並列複合アップロードに対応しているため、大容量ファイルの転送も追加のツールなしで対応できます。
あわせて、VPC Service Controls と必要最小限の権限のみを付与したサービスアカウントにより、閉域内であっても「アップロードに必要な操作しかできない」構成としています。

OCX(Open Connectivity eXchange)による閉域接続

石狩DCからの接続にはさくらインターネット社のサービスである、OCX を利用させていただきました。石狩DC内では、ラック内の物理環境から他サービスへ閉域接続するための [ハイブリッド接続] と、OCXへ接続するためのGWサービスとなる[プライベートリンク for BBIX]も利用されています。
各サービスの詳細はこちらご参照ください。

Partner Interconnect の開通までの具体的な流れ(ペアリングキーの発行や VLAN アタッチメントの有効化など)は、前回記事で詳しくご紹介しています。

冗長化を考慮した閉域ネットワーク設計

Google Cloud が推奨する 99.9% 可用性構成に沿って冗長化を行いました。

項目 設計内容
VLAN アタッチメント 冗長な VLAN アタッチメントペア(A/B)を作成
Cloud Router 東京リージョン(asia-northeast1)に配置、Google ASN を設定
BGP オンプレミス側(ピア ASN)と動的経路交換、MD5 認証を有効化
動的ルーティングモード VPC をグローバルルーティングに変更
カスタムアドバタイズルート PSC エンドポイント(IPアドレス)をオンプレミス側へ広報

設計上のポイントを2つ挙げます。

BGP カスタムアドバタイズルートによる PSC エンドポイントの広報
PSC エンドポイントの IP アドレスはサブネットの範囲外で払い出されるため、デフォルトの経路広報ではオンプレミス側に伝わりません。Cloud Router のカスタムアドバタイズルートで PSC エンドポイントの IP アドレスを明示的に広報することで、石狩DC側から Google API へ閉域経路で到達できるようにしています。

BGP MD5 認証
閉域網とはいえ、経路交換を行う BGP セッションには MD5 認証を設定し、意図しないピアとのセッション確立を防いでいます。

閉域網での名前解決と Google API アクセス

閉域網でクラウドを利用する際に意外と悩ましいのが「名前解決」です。インターネットに出られないため、パブリック DNS は利用できません。

本構成では、次の2段構えで名前解決を閉域内に完結させました。

  1. Cloud DNS のプライベートゾーンで *.googleapis.com を PSC エンドポイント(IPアドレス)に名前解決するよう定義
  2. Cloud DNS インバウンドエンドポイントを作成し、石狩DCのアップロードサーバの DNS 参照先として設定

これにより、アップロードサーバ上で gcloud コマンドを実行すると、storage.googleapis.com などの API ドメインが PSC エンドポイントへ解決され、すべての API 通信が Partner Interconnect 経由の閉域経路を通る構成となります。

現地での開通確認も、以下のようにシンプルなコマンドで実施できます。

# 名前解決の確認: googleapis.com が PSC エンドポイントの IP アドレスに解決されること
dig storage.googleapis.com

# PSC エンドポイントへの疎通確認: HTTP 204 が返ること
# ENDPOINT_IP には PSC エンドポイントの IP アドレスを指定
curl -v ENDPOINT_IP/generate_204

この疎通確認は、Google Cloud 公式ドキュメントに記載されている PSC エンドポイントの検証手順に基づくものです。エンドポイントが正常に機能している場合、HTTP 204 レスポンスが返されます。

Fluent Bit によるログ収集と Cloud Logging への連携

監視方式の検討

理化学研究所様から「クラウド側からDC側サーバへ向けた通信は、監視目的でも極力避けたい」というご要望をいただき、アップロードサーバから Cloud Logging へ一方向にログを送信し続け、ログが届かなくなったことを異常として検知する方式を採用しました。

観点 ping 監視(ポーリング型) ログ送信方式(採用)
クラウド→DC方向の通信 発生する 発生しない(DC→クラウドの一方向のみ)
中継サーバ障害時の影響 踏み台VM障害が監視に影響 影響なし(Cloud Logging へ直接送信)

Fluent Bit の実装

ログ転送エージェントには軽量な Fluent Bit を採用し、Docker コンテナとして稼働させました。閉域網のためコンテナイメージを直接 pull できず、事前に docker save したイメージを持ち込み、現地で docker load する運用としています。

Fluent Bit の構成は次のとおりです。

[INPUT]  cpu     — 60秒間隔で CPU メトリクスを送信(死活監視のキープアライブとして利用)
[INPUT]  tail    — /var/log/syslog(システムログ)
[INPUT]  tail    — /var/log/auth.log(認証ログ)
[OUTPUT] stackdriver — サービスアカウントキーを利用し Cloud Logging へ転送

CPU メトリクスの INPUT は、リソース監視というより「サーバとログ転送経路が生きていることを 60 秒ごとに知らせるハートビート」としての役割を担っています。
あわせてシステムログと認証ログを転送することで、閉域網内のサーバでありながら、ログの確認はすべて Google Cloud コンソール側で完結できるようになりました。

なお、コンテナランタイムについては、その後、理化学研究所様にて Docker から Singularity への移行が実施され、現在は Singularity 上で Fluent Bit が稼働しています。

Cloud Monitoring を活用した監視設計

死活監視は Cloud Monitoring のアラートポリシーで実装しました。ポイントは、条件タイプに Metric absence(メトリクスの欠落) を利用している点です。

項目 設定内容
監視対象 Fluent Bit が送信するキープアライブ用ログ(CPU メトリクス)
条件タイプ Metric absence — 5分間データが届かない場合に発報
通知 メール通知(通知チャネルに運用担当者を登録)
インシデント 復旧後の自動クローズを有効化(1日)
重要度 Critical

「ログが5分間届かなければ異常」というシンプルなルールで、サーバダウン・Fluent Bit の停止・閉域経路の断のいずれも検知できます。

構築後には、Fluent Bit のコンテナを実際に停止する発報テストを行い、アラートメールの通知から復旧時の自動クローズまで確認しています。

実現できたこと(まとめ)

本構成により、次のことを実現できました。

  • アップロード時にインターネットを経由しない研究データの搬送経路
    石狩DC → OCX → Partner Interconnect → PSC エンドポイント → Cloud Storage というエンドツーエンドの閉域経路を確立しました。名前解決を含めてすべての通信が閉域内で完結しています。
  • 冗長性を確保した閉域ネットワーク
    VLAN アタッチメントの冗長ペアと BGP による動的経路制御で、99.9% 可用性構成に沿った設計としました。
  • クラウド中心の運用監視
    遠隔地の閉域網内サーバのログを Cloud Logging に集約し、Cloud Monitoring の Metric absence によるプッシュ型死活監視を構築しました。DC側へのインバウンド通信を増やすことなく、サーバの状態把握とアラート通知を実現しています。

閉域網の構築というと、ネットワークの開通がゴールになりがちですが、実際には「閉域網の中のサーバをどう運用し続けるか」まで含めて設計することで、はじめて安心して使える基盤になります。
今回は、ポーリング型ではなくログ送信型の死活監視を採用することで、セキュリティ要件と運用性を両立できました。

本プロジェクトでは、石狩DCでのオンサイト対応含め理化学研究所様の石川 哲朗様、盛 文香様、芦崎 晃一様にご担当いただきました。
閉域網構築ならではの現地での動作確認など、リモートだけでは完結しない部分を支えていただいたことが、今回の構成を実現する上で欠かせませんでした。

弊社からは、齋藤 寛隆、米田 和輝、吉野 智彦がネットワークの設計・構築から監視設計までを担当いたしました。
この場を借りて、御礼申し上げます。

本記事で共有した内容が、閉域網とクラウドの接続を検討されている方の参考になれば幸いです。