オンプレミスとGKEを併用したインフラについて

こんにちは、IT基盤部の宮崎です。
DeNAが提供するヘルスケア系サービスのインフラを担当しています。
今回は、クラウド移行とアーキテクチャ刷新に取り組んでいるプロジェクトがオンプレミスとGKEを併用する構成になりましたので、クラウド移行の過渡期にあたるシステムの紹介を通し構築過程で得た気づきをお伝えさせていただきます。詳細はドキュメントに頼る事が多く説明不足な所があると思いますが、何か得られるものを見つけていただければ幸いです。

概要

はじめに、アーキテクチャ刷新の目的とクラウドプラットフォーム選定の経緯を簡単に紹介します。
その後、システム概要図から、クラウド環境に焦点をあて分割していきます。
アプリケーションはGKE上で動作し、SharedVPCで払い出すネットワークを利用してオンプレと通信します。

アーキテクチャ刷新の目的

オンプレミスのシステムに以下の課題を持っていました。

事業展開スピードに合わせて、プロダクト改善を進められるようにしたい
テストの所要時間が長い
デプロイにかかる時間が長い
コンポネントを容易に増やしたい
パフォーマンス面の懸念を動的に解決したい

それを解決するためにコンテナ技術を活用,マイクロサービスアーキテクチャを採用することに決定。

クラウドプラットフォーム選定の経緯

以下の要件や構想を元に、AWSとGCPを候補に検討をはじめました。

アプリケーションレイヤーにKubernetesを利用する。
- 懸念無し (ECS, EKS, GKE)
外部連携のデータ受け渡しは専用線を利用する。
- オンプレからセキュアにデータ転送する。
  - restricted.googleapis.com で提供されるAPIを使えばいけそう
  - Private Google Access
  - Access Option
マネージドサービスを積極的に利用する。
- CloudMemoryStoreがベータいつGAになるか不明
- CloudSQLのメンテナンス時間 (CloudSQL Proxyの管理どうする)
- 懸念なし (LB, RDB, Redis, Storage 等の利用予定のマネージドサービス)
BigQueryを分析で利用する。

どちらも機能は備えているが、クラウド上に我々の運用フロー(作業証跡・認証)を別途準備するのは変わらない
BigQuery利用する事が決まっているから、アカウント管理を考えるとGCPに統一した方が楽なのではないか？この事からGCPをメインで検証を進め、最終的にこのプロジェクトはGCPを利用する事に決めました。 2018年秋頃に検討したものなので、2019年9月現在は状況が変わっていると思います。

システム概要図

システムの構成要因は、以下の通りです。

システム環境
- GKE環境
- オンプレミス環境
外部連携システム
- ファイル授受
外部サービス
- 外部API連携
システム利用者
- サービスユーザ
- 社内メンバー(企画、CSメンバーなど)

これらの関係を図示すると以下のようになります。

オンプレミス環境には既存システムが存在しています。GKE環境からオンプレのSFTPサーバ・メールサーバを利用しています。オンプレ依存を少なくするため外部メールサービス利用を検討しましたが、完全移行まで費用を抑えたい事と海外事業者への第３者情報提供をしないなどの制約を満たすため、完全移行まではオンプレのメールサーバを利用する事にしました。

アプリケーションは全てGKE上で動作し、積極的にマネージドサービスを利用しています。
GKE環境を、クラウドサービスのコンポネントで置き換えると以下のような構成です。

次に、オンプレとどのように接続しているかを説明するため、ネットワークとGCPプロジェクトについて紹介します。

ネットワークとGCPプロジェクト

GCPのネットワークリソースは、リージョン・プロジェクトを跨いで存在できるので、HostProjectで一括管理しServiceProjectにリソースを払い出す事にします。こうするとオンプレとGCP間のVPN接続を３環境(開発, ステージング, 本番)準備する必要があるところが１環境に集約出来てVPN接続を減らすことが出来ます。

VPN接続一系統(2本)の費用約[110 USD/月]

ネットワーク管理とログ管理の2つの視点から次の通りGCPプロジェクトを分割しています。

HostProject
- ネットワークの一括管理、SharedVPCでServiceProjectへ払い出す、VPN接続・Firewallルール管理
ServiceProject
- HostProjectから払い出されたネットワークを利用してGKEクラスタ上でアプリケーションを動かす
AuditProject
- 監査ログを保存するプロジェクト

これらの関係を図示すると以下のようになります。ServiceProject, AuditProjectのみ環境毎に存在します。

SharedVPCとアドレス設計

SharedVPCでServiceProjectにネットワークを払い出すのですが、クラスタサイズを決めるためアドレス設計が必要になります。

Defaults and Limits for Range Sizes の通り、標準設定では大量のIP(Node:/20 + Pod:/14 + Service:/20)を必要とします同様に潤沢に割り当てたいところですが、オンプレと通信するため他の環境と重複しないようにアドレス管理が必要になります。オンプレとクラウドのネットワークの話の通りサービス数が多く、サービス規模に合わせたアドレス設計が必要です。

"Considerations for Cluster Sizing"を参考にNodesを決めるとPodが決まります。
ServiceのIPは削減できると思いますが、GKEクラスタ操作用のoperation networkも含め(/15)に収まるようにしています。

## 合計 (/15)
-------------
## GKEクラスタ
Nodes   : /24
Pod     : /16
Service : /20

## Operation
bastion : /24

クラスタを追加する場合には、Serviceネットワークのみ別途割り当てる。
性能不足にはNodesのScaleUPで当面対応できると考えてました。

これらの関係を図示すると以下のようになります。

GKEクラスタ

ネットワーク割り当てが完了しましたので、クラスタを構築したいと思います。
セキュリティを考慮し限定公開クラスタとし、マスターの制御元をoperation networkに限定するためマスター承認済みネットワークとします。

キーワードと、ドキュメントは以下を参考にしています。

共有VPC内に限定公開クラスタを作成する
限定公開クラスタ
- VPCネイティブクラスタ
- VPCネットワークピアリング
マスター承認済みネットワーク
VPC Network Peering
authorized networks

以上をまとめると、クラスタ作成するコマンドは次のようになります。

cluster_name=FOO-BAR-platform-green
network_project_id=dena-FOO-BAR-platform-nw-gcp  # HostProject  
vpc_network=vpc-FOO-BAR-platform-1
subnetwork=subnet-FOO-BAR-platform-1-ane1-node-172-17-100-0-24
pod_range=subnet-FOO-BAR-platform-1-ane1-pod-172-16-0-0-16
service_range=subnet-FOO-BAR-platform-1-ane1-service-172-17-0-0-20
master_range=172.18.0.0/28
authorized_network=172.17.200.0/24 # operation network
num_node=6
node_type=n1-standard-4

gcloud beta container clusters create $cluster_name \
--enable-autoupgrade \
--enable-ip-alias \
--enable-private-nodes \
--enable-private-endpoint \
--enable-master-authorized-networks \
--no-enable-basic-auth \
--no-issue-client-certificate \
--master-authorized-networks $authorized_network \
--network projects/$network_project_id/global/networks/$vpc_network \
--subnetwork projects/$network_project_id/regions/asia-northeast1/subnetworks/$subnetwork \
--cluster-secondary-range-name $pod_range \
--services-secondary-range-name $service_range \
--master-ipv4-cidr $master_range \
--cluster-version=latest \
--enable-stackdriver-kubernetes \
--machine-type=$node_type \
--num-nodes=$num_node \
--tags=$cluster_name

最後にアプリケーションをデプロイし、セキュリティ構成を付加したサービスレベルの俯瞰図は次の通りになります。

最後に

今ではサービスを提供出来る状態になりましたが、ここに到るまでSharedVPC環境でクラスタが作成出来ない・SharedVPC配下でGKE Ingressリソースが作成出来ないなど、構築過程でさまざまな問題がありました、エラーログを元に調査しても手がかりが無い場合もありサポートケースやGCP Office Hourで相談しながら都度解決してきました。その情報は英語・日本語共にドキュメントを修正していただきましたが、日本語への反映には時間がかかる事に気づきました。

ドキュメントのリンク先を英語で書きましたが、これが今回お伝えしたい気づきです。

❗ 英語のドキュメントも読もう。❗

常識的な事かもしれませんが、日本語と英語のドキュメントの乖離はあり、一年以上に及ぶのもあります。