More Related Content
Similar to CNDT2022_たまにはオンプレもいいぞ? GKE と Armadillo IoT で実現する ハイブリッドクラウド (20)
More from Ryo Sasaki (10)
CNDT2022_たまにはオンプレもいいぞ? GKE と Armadillo IoT で実現する ハイブリッドクラウド
- 3. 佐々木 了
Ryo Sasaki
2012/04
2017/07
某 通信系SIer 入社
・元々はNWエンジニアだったので BGP使った他拠点 NW作ったりとか
・自治体とか官公庁系システムに携わったりすることが多かったかな
・橋梁点検ロボット開発やったりとか
フリーランスに転向
・ペネトレーションテストやったりとか
・OpenStatkとOpenShift結構やってたりとか
・ハイブリッドクラウド作ったりとか
2021/11 ビットキーにSREとしてジョイン
※ぶっちゃけあまり SREやってないけどね
公の場で人に説明できるような輝かしい経歴は持ってないので
サクッと流します!!!
- 11. CONFIDENTIAL © Bitkey Inc. All rights reserved. 11
Connect everything
through the power of technology, securely and conveniently in a way, that simply feels good
テクノロジーの力で、あらゆるものを
安全で 便利で 気持ちよく
「つなげる」
Our Mission
- 50. 新構成: ハイブリッドクラウド
コンセプト
50
● オンプレ側にはサーバーは置かない
● 冗長性を持たせたNW機器を最小限置く
● アプリケーション機能は全てGCPのGKEに置く
○ マルチリージョン構成で可用性をさらに向上
○ Autopilotモードによる運用の簡略化
● モバイル回線を使ったマルチキャリア経路を持たせる
○ VPNによってローカルエリアをクラウドまで延伸
● 単一物理構成であらゆるお客様の環境と制御盤に対応
※ごめんなさい。社内事情がありまして、この部分は今日は撮影しないでください。あとで必ず資料公開します。
- 58. 新構成: ハイブリッドクラウド
58
● NICや電源が二重化されているわけではない
● LTEも機器単体では1キャリアしか扱えない
● しかし、軽量で安価なArmadilloをたくさん用意してスケールアウト性を持たせる
○ 単一のArmadilloがダメになっても副系に勝手に切り替わればいいだけ
○ 高いお金を払って強いサーバーで内部的に二重化させるほどでもない
○ ケーブル繋ぎかえてはい終わり!のような交換容易性を持たせておく
IoTとしての採用例が多いArmadilloを採用
- 59. 新構成: ハイブリッドクラウド
Flexibility
59
● GCP側にメインのアプリケーション機能があるためどうにでもなる
● 原則GKEでホスティングしているが、当然他の
GCPサービスも利用して連携できる
● k8sとしての強力なエコシステムに乗っかりつつ、
Autopilotによって面倒なノード管理は自分達の手から離す
○ AutopilotとStandardの違い: https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-standard-feature-comparison?hl=ja
● 今後、PodやServiceを増やしたくなってもいくらでもどうにでもなる
- 61. 新構成: ハイブリッドクラウド
61
● NW機能は strongswan + BIRDでVPN + BGPを実現
○ ArmadilloにOSSを組み合わせることで、
市場に出回っているまともなNW機器に負けない機能を得られる
○ もちろんIPsecのHWオフロードとかできないし、
ルーティング性能もスイッチング能力も本職は負けるけど、
今回のワークロード的には全然余裕
Flexibility
- 65. 新構成: ハイブリッドクラウド
65
● 可用性
○ マルチリージョン構成/ マルチキャリアNWを前提にしたことで大幅に向上
○ 旧構成では人間による現地作業の切り替えが必要だったが
新構成では自動切り替え
● コスト
○ 旧構成の1/3程度に圧縮
● 運用保守性
○ 初期設計時点で24365を見据えたモニタリングを想定
○ 運用保守フローも整備し、非エンジニアであっても一次対応が可能
- 87. 商用ハイブリッドクラウドのための妄想力
妄想力: オンプレ
87
● 物理系
○ 電源ユニットが死ぬ
○ NICが死ぬ (どこかのポートだけ死ぬ)
○ 死ぬならまだマシだが、中途半端な半死状態になる
○ メモリのECCエラーが多発して断続的に再起動かかる
○ ケーブリング不備
○ そもそもケーブルの品質が低い
○ 周囲環境のノイズが激しい
○ 空調がない or 空調の調子が悪くて暑い
○ インターネット回線のキャリア障害
こんなの序の口。
まだまだたくさんある。
- 100. 今回の事例における技術要素の紹介
100
● HTTPS通信が前提なら Multi Cluster Ingress が簡単
○ 参考: https://cloud.google.com/kubernetes-engine/docs/concepts/multi-cluster-ingress?hl=ja
○ 今回の場合、HTTPに限らない様々なプロトコルを扱う必要がある
○ つまり使えない、不採用
● 似た理由でAnthos Service Meshも不可
○ UDPを扱えない・・・マルチリージョンな LBなら結局外部LBが前提
○ 参考: https://cloud.google.com/service-mesh/docs?hl=ja
- 101. 今回の事例における技術要素の紹介
101
● Multi Cluster Serviceであれば、L4をそのまま扱えるので自由度が高い
○ 参考: https://cloud.google.com/kubernetes-engine/docs/concepts/multi-cluster-services?hl=ja
○ 通信要件としてはクリア
○ しかし、GKEインターナルなVIPに
なってしまうので外部から扱えない
○ 不採用
- 108. 今回の事例における技術要素の紹介
注: 現状GUIサポートがないのでCLIを使う必要アリ
108
# gce-vm-ipなNGEを作成
gcloud compute network-endpoint-groups create tokyo-neg
--network=default
--subnet=default
--network-endpoint-type=gce-vm-ip
--zone=asia-northeast1-b
# backend-serviceを作る時点で少しパラメーターを増やす
gcloud compute backend-services create tokyo-backend-service
--region=asia-northeast1
--load-balancing-scheme=INTERNAL
--protocol=TCP
--health-checks=your-healthcheck
--health-checks-region=asia-northeast1
# gce-vm-ipなNEGをバックエンドとして追加する
gcloud compute backend-services add-backend tokyo-backend-service
--network-endpoint-group=tokyo-neg
--network-endpoint-group-zone=asia-northeast1-b
--region=asia-northeast1
- 109. 今回の事例における技術要素の紹介
109
# Routing PolicyとしてアタッチするためのForwarding Rule
gcloud compute forwarding-rules tokyo-forwarding-rule
--region=asia-northeast1
--load-balancing-scheme=internal
--network=default
--subnet=default
--ip-protocol=TCP
--ports=8080
--backend-service=your-backend-service
--backend-service-region=asia-northeast1
# 東西冗長のためのForwardingRuleをそれぞれアタッチしながらFailover可能なAレコードを作成
gcloud dns record-sets create ha.example.local
--ttl=30
--type=A
--zone=your-private-zone
--routing-policy-type=FAILOVER
--enable-geo-fencing
--routing-policy-primary-data=tokyo-forwarding-rule
--routing-policy-backup-data-type=GEO
--routing-policy-backup-data="asia-northeast2=osaka-forwarding-rule"
--backup-data-trickle-ratio=0
--enable-health-checking
- 116. 今回の事例における技術要素の紹介
Armadilloの下準備
116
● ArmadilloのデフォルトLinux Kernelは最低限の機能しか組み込まれていない
○ 認証や暗号化を司るAHやESP関連のカーネルモジュールが組み込まれていない
○ つまりデフォではIPsecをはれないのでKernelを再ビルドする必要がある
# Networking Support > Networking options > ESP Transformation と AH Transformation を有効化
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig
# この時点でカーネル再ビルドは完了
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j5
# 実際にはここでArmadilloならではのゴニョゴニョが必要だが割愛
# 成果物の.swuがArmadilloで書き込めるファームウェアイメージ
$ mkswu -o update-kernel.swu update-kernel/update-kernel.desc
- 117. 今回の事例における技術要素の紹介
Armadilloの下準備
117
● Atmark Techno Development Environmentという公式に提供されるVMを使えば、Armadillo用
のカーネルビルドなどを簡単にやり始められるのでオススメ
○ 参考: https://armadillo.atmark-techno.com/guide/atde
● ただしそのままでは単一マシンに対する
VMとしてしか扱えないので、
今回はGCEにインポートさせて共有VMのような感じにした
○ 関連メンバーが誰でも使えるように
# VMの.vmdkを事前にGCSにアップロードしておく
# そのvmdkをインポートさせてGCEインスタンスを作成
$ gcloud compute images import [your-vm-name] --source-file "gs://path/to/atde.vmdk"
- 139. 理想と現実のギャップを埋める
139
● Anthos Clusters on bare metal の可能性
○ オンプレ側でマネージドなk8sを動かしてGCPから管理できる
○ めちゃくちゃ便利!本来なら面倒なオンプレ側のk8sをマネージドに扱える
● 不採用の理由
○ 要求スペックが高く、それを満たすための機器を買おうとするとコストが嵩む
○ オンプレ側でゴリゴリにk8s動かしたいほどのワークロードはない
○ そんな鈍重な構成にしたくない
- 142. 理想と現実のギャップを埋める
142
● モバイル回線 + 閉域網を使うケース
○ 特に何も構成せずともSIM挿すだけでGCPとローカル通信が可能になる
○ VPNの管理/メンテナンスコストを低減可能
○ おそらく、今回のような他拠点・不特定多数のハイブリッドクラウド構築でもない限りは、正直
閉域網を使った方が楽だと思う
- 145. 理想と現実のギャップを埋める
145
● 専用NW機器の検討も当然してみた
○ Ciscoでいえば C1111-8PLTELA とかなら有線GbEもLTEも使える
○ 各社少なからず似たようなのがある
● 最初に検討したのがこれ系だったのが、
万が一の潰しが効かない
○ そりゃIPsecのHWオフロード効かせるようなスループットやら
NAT性能やらが
欲しいならこういう系を使うべきだが今回はそこまでのパフォーマンスは不要
○ だとすれば、汎用性が高い方を選びたかった= LinuxのNW機器化
● 調達リードタイムが長くなりがち
○ 上述のC1111-8PLTELAだと納期約10ヶ月。。。