[Cloud Native Days Tokyo 2022] たまにはオンプレもいいぞ？ GKE と Armadillo IoT で実現する ハイブリッドクラウド
•
0 likes•195 views
Cloud Native Days Tokyo 2022 セッション資料
Recommended
Recommended
More Related Content
Similar to [Cloud Native Days Tokyo 2022] たまにはオンプレもいいぞ？ GKE と Armadillo IoT で実現する ハイブリッドクラウド
Similar to [Cloud Native Days Tokyo 2022] たまにはオンプレもいいぞ？ GKE と Armadillo IoT で実現する ハイブリッドクラウド (20)
More from Ryo Sasaki
More from Ryo Sasaki (9)
[Cloud Native Days Tokyo 2022] たまにはオンプレもいいぞ？ GKE と Armadillo IoT で実現する ハイブリッドクラウド
- 1. たまにはオンプレもいいぞ？ GKE と Armadillo IoT で実現する ハイブリッドクラウド 株式会社ビットキー 佐々木 了
- 2. たまにはオンプレもいいぞ？ GKE と Armadillo IoT で実現する ハイブリッドクラウド 株式会社ビットキー 佐々木 了
- 3. たまにはオンプレもいいぞ？ GKE と Armadillo IoT で実現する ハイブリッドクラウド 株式会社ビットキー 佐々木 了
- 4. たまにはオンプレもいいぞ？ GKE と Armadillo IoT で実現する ハイブリッドクラウド 株式会社ビットキー 佐々木 了
- 5. Outline 1. 今までの構成と問題点 2. 新構成に向けて 3. 新構成: ハイブリッドクラウド 4. 今回の事例における技術要素の紹介 5. 如何に妄想するか 6. 現実と理想のギャップを埋める 5
- 6. 佐々木 了 Ryo Sasaki 2012/04 2017/07 某 通信系SIer 入社 ・元々はNWエンジニアだったので BGP使った他拠点 NW作ったりとか ・自治体とか官公庁系システムに携わったりすることが多かったかな ・橋梁点検ロボット開発やったりとか フリーランスに転向 ・ペネトレーションテストやったりとか ・OpenStatkとOpenShift結構やってたりとか ・ハイブリッドクラウド作ったりとか 2021/11 ビットキーにSREとしてジョイン ※ぶっちゃけあまり SREやってないけどね 公の場で人に説明できるような輝かしい経歴は持ってないので サクッと流します！！！
- 7. お伝えしたいこと 7 ● ハイブリッドクラウドには妄想力が必要不可欠 ● 寝よう / 寝かせよう ● 最強は最善ではない
- 8. 8 おねがい
- 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
- 16. 16
- 17. 17
- 19. 今日の話
- 20. 20
- 22. 22
- 23. 23 今日の話
- 24. 24
- 25. 今までの構成と問題点 25
- 26. 26 ここの話！
- 27. 今までの構成と問題点 27 ● ビルの地下深くの制御盤近くにWindowsサーバーを2台設置 ● NW機器もいくつか導入して、 そこをビットキー責任境界としてインターネットに出ていく ● SaaSが稼働しているパブリッククラウド (GCP)と 協調しながら制御盤との連携を行う 今までの構成
- 29. 今までの構成と問題点 29 ● ビットキーのプロダクトの中で 唯一物理サーバーを用いるオンプレ構成 ○ それ以外は全てフルサーバーレス構成 ○ GCF / CloudRun / GKE (今回は詳細を割愛 ) ● 社内にオンプレ側を扱う技術的なノウハウが乏しい ● 可用性が低く、障害時には手動での切り替えが前提 ● 物理ならではの長期間使い続けるための運用保守意識が乏しい 問題点
- 30. 今までの構成と問題点 30 ● しかも、それぞれのお客さまごとに構成を変えていた ● 個社対応が多すぎて管理がしきれない ○ N+1で増えていくオンプレ機器たちをどうやって管理していく？？ ユーザーA ユーザーB ユーザーC ・・・ 問題点
- 31. 今までの構成と問題点 ● HW的な故障に対する備えが不十分だった ○ 監視体制がない ○ NW機器やサーバーに何かが起きた時の復旧手順を確立できていない ● アップデートが困難/難解 ○ そもそも24365稼働なので簡単に止められないという要素が大きい ○ その上で、自動的なデプロイの仕組みがあったわけでもないので、 毎回お客様と調整の上、メンテナンス時間をもらって デプロイコマンドを叩く・・・みたいな感じ 31 問題点
- 32. 今までの構成と問題点 32 ● 営業〜導入支援の段階では、営業部隊/プロジェクト推進チームが主導する ○ ゼロベースでお客様へのヒヤリング〜構成の検討〜見積もり〜微調整〜を担当 ○ 知見が十分ではない中、ベンダーとのやり取りも非常に難しく工数が嵩む ● お客様への金額感の提示だけでもリードタイムが長くなってしまう ● 実際の導入に向けた詳細設計の負担も大きく、その複雑さから手戻りが出てしまうことも ○ 物理機器がなければ何も動かせないので、 プロジェクト推進のクリティカルパスになりがち 問題点
- 33. 今までの構成と問題点 33 ● こういったビル環境では、実はまともなNWが存在しないというケースもある ○ その場合、お客様には新しく回線を引いてもらう必要がある ○ 手間がかかって面倒だしリードタイムが伸びてしまう ● 一方でNWが存在するケースもある ● こういった個々のビル毎の事情の違いが、お客様毎に毎回構成を変えている要因 問題点
- 34. 今までの構成と問題点 34 ● このままじゃまずい！と考えたので諸々修正やら整備を実施 ○ モニタリング/アラーティングの実装 ○ 運用保守のマニュアルや対応フローの確立 ○ 営業段階での技術的支援 これをずっと続けるのは流石に厳しい・・・
- 35. 今までの構成と問題点 35 ● 今後のworkhubのEnterprise領域の拡大を見据えると、制御盤連携は非常に重要な要素 ○ 大きなお客様であればあるほど「 ビル全体の制御」の需要は高い ● その中で、今までのような一社あたりに構成をゼロから考えて・・・ ノウハウの少ないオンプレ側をどうにか頑張って・・・というのは、 今後の導入拡大の中で足枷 になってしまう どうにかしたい！！！ リアーキテクチャを検討開始
- 36. 新構成に向けて 36
- 37. 新構成に向けて 37 ● とにかく面倒ごとが多いオンプレ側の要素を減らしたい ○ 社内に詳しいエンジニアが少ない ○ 現状は社外ベンダーと協力が必須 ○ そんな状態から抜け出したい ● 可能な限り自分たちの得意分野に寄せてスキルの応用性を高めたい ○ そうすることで、自分たち自身で正しく構成や仕組みを設計 /評価/判断したい 想い
- 38. 新構成に向けて 38 ● オンプレ側を弱くした結果、さらに可用性が失われたりすることはあってはならない ○ というか、今までよりも優れた可用性を発揮させたい ○ 可能な限りダウンタイムを減らし、 制御盤連携ができない時間や遅延を発生させたくない 想い
- 39. 新構成に向けて 39 ● 万が一に備えたモニタリング/アラーティングを前提にした設計を行い、 HW障害やGCPリージョンが丸ごと死ぬような最悪なケースであっても サービスは継続させたい ○ 導入した結果、障害によって”トビラが開かない”ことがある、なんてダメ ● コストを圧縮させ、今までよりもお客様に価格的訴求力のある提供 をしたい 想い
- 40. 新構成に向けて 40 ● オンプレ&物理サーバーでなければならない強い理由がある・・・？ ○ そこまで強い理由は・・・・・ない ● Windowsサーバーである理由がある・・・？ ○ ・・・・・ない 正直なところ
- 41. 新構成に向けて 41 ● 現状はこの制御盤連携を伴うような workhubの導入は大都市圏に限られている ● しかし、今後は津々浦々に増えていく可能性 がある ○ 全国規模の様々なビルに導入されていく ● 単一ロケーションのどこかを対応して、はい！終わり！ではない ○ 高い再現性を持って全国展開させていかなければいけない 今後の導入拡大を考えれば、このままではいけない
- 42. 新構成に向けて 42 ● オンプレ側の構成をスリム化し、 他プロダクトと同じようにクラウド側で処理できないか？ ● そうした標準構成を策定することで、どのお客様でも同じ構成で導入できないか？ ● ビットキーとして制御盤連携のためのアプライアンスを提供 するイメージ
- 43. 新構成に向けて 43 ● そうすれば少なくとも物理構成は統一してお客様に提案 /説明が可能 ● 金額感も伝えやすいし見積もりを出すまでのリードタイムも大幅に削減可能 ● ただし、どのお客様にも適合できるような構成にする以上、 場合によっては無駄も出てしまうだろう ○ しかし、これ1つで全部に使える！どんどん提案していける！という スケールバリューの方が高いと判断
- 45. 新構成: ハイブリッドクラウド そもそもの話 45 ● 制御盤はビル内部にしか存在しないし、グローバルに露出も当然していない ● とにかく、そこに対するローカルIP通信がしたい ● それ以外にオンプレ側に用事はない なら、NW的にそれを担保してあげれば良いだけだよね？ 別にサーバーを現地に置く必要なくない？
- 50. 新構成: ハイブリッドクラウド コンセプト 50 ● オンプレ側にはサーバーは置かない ● 冗長性を持たせたNW機器を最小限置く ● アプリケーション機能は全てGCPのGKEに置く ○ マルチリージョン構成で可用性をさらに向上 ○ Autopilotモードによる運用の簡略化 ● モバイル回線を使ったマルチキャリア経路を持たせる ○ VPNによってローカルエリアをクラウドまで延伸 ● 単一物理構成であらゆるお客様の環境と制御盤に対応 ※ごめんなさい。社内事情がありまして、この部分は今日は撮影しないでください。あとで必ず資料公開します。
- 51. 新構成: ハイブリッドクラウド 51 これさえ入れてくれたら・・・ ● 簡単に制御盤連携できまっせ！ ● ビル全体制御できちゃうよ！ という ビルオートメーションの 垂直統合アプライアンスを提供 ※実はまだ名前が決まってません ※ごめんなさい。社内事情がありまして、この部分は今日は撮影しないでください。あとで必ず資料公開します。
- 52. 新構成: ハイブリッドクラウド 52 ● 実際に制御盤連携を行うアプリケーションは Goで実装 ● 制御盤連携を抽象化 ○ 様々な制御盤用のプロトコルをサポートし、複数ベンダーの制御盤を操れる ○ TCP / UDP / 独自プロトコル etc. ● そのアプリケーションをコンテナ化し GKEにて稼働させる ● VPNを通じてビル内のNWに入り込みローカル通信させる
- 53. 新構成: ハイブリッドクラウド 53 ● モバイル回線(LTE)を使ったNW経路をサポート ○ これでわざわざ有線インターネット回線を引かなくて済む ○ ワークロード的にはモバイル回線程度のスループットやレイテンシでも 十分戦える
- 54. 新構成: ハイブリッドクラウド 疑問 54 ● ビルの地下だと電波届かないのでは？ ○ 本プロダクトを導入するような大きめのビルだと国内 3キャリアのうち、 いずれかの屋内基地局が敷設されているケースは珍しくない ○ その場合は、地下であろうが電波は届く
- 55. 新構成: ハイブリッドクラウド 55 ● 物理構成パターンは1つのみ ● その1つですべてのお客様に対応できる ○ わざわざ回線を引き込みたくないケースの NW ○ 回線を引き込むケース ○ 既設NWが存在するケース ● どのお客様であっても組み込み可能で、 かつ、想定する可用性を発揮できるような NW的な柔軟性を確保
- 56. 新構成: ハイブリッドクラウド IoTとしての採用例も多いアットマークテクノ社のArmadilloを汎用NW機器として採用 56 ● LTEをサポートし単独でインターネットに出れる ● 中身がLinuxであり、今回の例ではルーターとして使う ● podmanが最初から使えるので簡単にコンテナデプロイが可能 ● overlayfsがデフォで備わっており、 電源を落とせば基本的に全部のファイルが消失するのでセキュア ● 参考: https://armadillo.atmark-techno.com/
- 57. 新構成: ハイブリッドクラウド 57 ● ファームウェアが二重化されており万が一のリスク低減が可能 ○ A面がぶっ壊れてもB面に切り替えて逃げれる ○ 物理的に助けることができない遠隔環境でも安心安全にアップデートが可能 ● ファームウェアを丸ごとネット経由で入れ替えられる ○ 開発環境側で作り込み、実機に対しては丸ごとファームウェアを書き込む感じ ○ AnsibleやTerraformなどのIaCに頼らなくてもOK (使ってもいい) IoTとしての採用例が多いArmadilloを採用
- 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を増やしたくなってもいくらでもどうにでもなる
- 60. 新構成: ハイブリッドクラウド 60 ● ArmadilloはLinuxなのでつぶしが効く ○ GKEで動かしているコンテナをそのまま直接 Armadilloで動かせてしまう ○ x64とArmの違いはあるが、Golangなのでマルチプラットフォームビルドは 簡単だし、それに応じてコンテナイメージを並行して生成しておけば良いだけ ○ お客様によっては、クラウド側を使わないエッジ処理だけで完結すパターンも想定 Flexibility
- 61. 新構成: ハイブリッドクラウド 61 ● NW機能は strongswan + BIRDでVPN + BGPを実現 ○ ArmadilloにOSSを組み合わせることで、 市場に出回っているまともなNW機器に負けない機能を得られる ○ もちろんIPsecのHWオフロードとかできないし、 ルーティング性能もスイッチング能力も本職は負けるけど、 今回のワークロード的には全然余裕 Flexibility
- 62. 新構成: ハイブリッドクラウド 62 ● L3スイッチをわざと採用し様々なお客様 NWへのアタッチ可能性に備える ● 普通はL2スイッチで原則OK・・・なんだけどね ● これは拡張性という点でも優位 Flexibility
- 63. 新構成: ハイブリッドクラウド Scalability 63 ● GKEによって、アプリケーション側で色々やりたくなってもどうにでもできる ○ 必要なときに必要なだけ増やせる ● 原則、オンプレ側もスケールアウトさせる方向でどんどん強くしていける ○ もちろんはどこかで限界は迎えるが、ワークロード的に そこまで強烈にスケールさせることはない ○ 前述の通りポート数もそこそこある L3スイッチのおかげでかなり何でもやれる
- 64. 新構成: ハイブリッドクラウド Agility 64 ● パブリッククラウド側は言わずもがな瞬時に欲しいものが揃う ● オンプレ側はあえて国産メーカー品の納期短めの調達しやすいモノを選定 ● この半導体不足の環境下においても、おおむね 1週間で調達可能 ○ 国外メーカー品だとモノによっては下手すれば調達まで数ヶ月かかる・・・ ● “壊れない”ことを目指すのではなく、安価に素早く交換して復旧できる機動力を得る
- 65. 新構成: ハイブリッドクラウド 65 ● 可用性 ○ マルチリージョン構成/ マルチキャリアNWを前提にしたことで大幅に向上 ○ 旧構成では人間による現地作業の切り替えが必要だったが 新構成では自動切り替え ● コスト ○ 旧構成の1/3程度に圧縮 ● 運用保守性 ○ 初期設計時点で24365を見据えたモニタリングを想定 ○ 運用保守フローも整備し、非エンジニアであっても一次対応が可能
- 68. 商用ハイブリッドクラウドのための妄想力 ハイブリッドクラウドをやりたい理由って何だろう？ 68 ● 何らかの理由でオンプレ側と直接的な通信をさせたいケースがほとんどでは？ ○ インターネットを介したAPIコールでは遅い ○ より通信を安定させたい ○ レイテンシが重要な通信である
- 70. 商用ハイブリッドクラウドのための妄想力 70 原則、どのパブリッククラウドも割と簡単にハイブリッドクラウド自体は作れる ● VPN: IPsec + BGPによるSite-to-SiteかつダイナミックなNWを構築 ● 専用線: 確実 / 高速 / 安定に直接的なローカルNWを構築 どちらも、どのパブリッククラウドプラットフォームでサポートしている。 事例も割と世の中にいくらでもあるので、実はハイブリッドクラウド自体を作るのは簡単。
- 71. 商用ハイブリッドクラウドのための妄想力 71 ● ただし、VPNにせよ、専用線にせよ、VPCに直接的に入り込むような形になる ● つまりアプリケーションをどこに置いて、どう VPCにつなげるか？は重要 ○ 例えば、どのパブリッククラウドもフルマネージドな FaaSとかだと VPCとは切り離された世界にいたりする ■ つまりVPCとのやりとりをしてあげるためにはそれなりの設定が必要 ○ とはいえ今ではLambdaもCloudFunctionsもVPCへのアタッチを公式にサポートしているの で、全く難しいことではない
- 76. 商用ハイブリッドクラウドのための妄想力 76 ● お金さえかければ、作るだけなら実はそこまで難しいものでもない ● ただし、可用性も意識しだしたマジな商用系を考えると実は途端に難しくなる ● 変数がとたんに増えてしまう
- 79. 商用ハイブリッドクラウドのための妄想力 ヒント 79 ● サーバー側には何も問題はない ○ 部品が故障しているとか、OSの潜在的バグとかでもない ● NW機器にも何も問題はない ● ただ1台にだけ事象が発生 ○ 同じNWに繋がっている他のサーバーには何も問題がない ● その事象が発生する直前には少しラックを触る作業があった
- 80. 商用ハイブリッドクラウドのための妄想力 答え 80 ● そのサーバーを繋いでいた光ファイバーケーブルの曲げ限界ギリギリぐらいの ケーブリングをしていたから ○ もうちょいわかりやすくいうとRが小さい ○ そのためパケットが途中でロスしまくる= NWが不安定 問題なし 厳しい・・・ 無理！！！
- 81. 商用ハイブリッドクラウドのための妄想力 クラウドであれば、何か障害があったとしても原則待つだけしかできない 81 ● 待つしかできないからこそ、その待っている間もサービスを継続させるために、 マルチゾーンやマルチリージョンな構成にしておくことは大事 ● いっぽうで兆候を事前に知ることもできなければ、 障害に陥ったあとはもう祈るしかない:cry: :pray: ● ある意味難しいし、ある意味楽
- 82. 商用ハイブリッドクラウドのための妄想力 ハイブリッド = オンプレが入ってくると、全部自分たちの責任 82 ● めちゃくちゃ技術力があればパブリッククラウドよりも パフォーマンスや可用性を上げられる ● 下手にやれば、パフォーマンスもでないし障害も多く、 ランニングコストも高いシステムになってしまう ● うまくやらないと、良いとこどりどころか、悪いとこどりになってしまいかねない
- 84. 商用ハイブリッドクラウドのための妄想力 妄想力 84 ● こんなこともあるかもしれない、あんなこともあるかもしれない ● それを想像して、手を打っていかなかればならない ● もちろん全てを洗い出すことは難しいし、 洗い出したところで対策できるかどうかはわからない ● でも考えないわけにはいかない ○ 何が起きるかわからないし、何か起きたら自分たちの責任なのだから
- 85. 商用ハイブリッドクラウドのための妄想力 妄想力 85 ● とにかく妄想しまくって、ビジネスラインに合わせて、 ここは守ろう、これは仕方ないのラインを引く ● そうでないと現実的なハイブリッドクラウドは無理 ○ 妄想しまくって出てきた何かに対して 全て手を打つのは無理
- 86. 商用ハイブリッドクラウドのための妄想力 妄想力: クラウド 86 ● クラウドの単一ゾーンの障害: 当然あるからリージョナルな構成にしよう ● クラウドの単一リージョンの障害: ありうるよね、マルチリージョンな構成にしよう ● 日本国内の2リージョンの同時障害: なくはないけど、そこまでやる？？ ● Googleの海底ケーブルの障害: もはやマルチクラウドにしないと無理
- 87. 商用ハイブリッドクラウドのための妄想力 妄想力: オンプレ 87 ● 物理系 ○ 電源ユニットが死ぬ ○ NICが死ぬ (どこかのポートだけ死ぬ) ○ 死ぬならまだマシだが、中途半端な半死状態になる ○ メモリのECCエラーが多発して断続的に再起動かかる ○ ケーブリング不備 ○ そもそもケーブルの品質が低い ○ 周囲環境のノイズが激しい ○ 空調がない or 空調の調子が悪くて暑い ○ インターネット回線のキャリア障害 こんなの序の口。 まだまだたくさんある。
- 88. 商用ハイブリッドクラウドのための妄想力 88 ● 妄想し出すとキリがないのは事実 ● でも、全く考えないのはただの考慮漏れであり設計不足 ● そしてそういうのをIT業界はずっとやってきて、だからこそクラウドが流行ったわけだ ○ 自分達があーだのこーだの考えてもコストや技術的に対策が難しい部分だってある ○ 莫大な資金と技術を持ったパブリッククラウドにおんぶに抱っこ最高！！！
- 89. 商用ハイブリッドクラウドのための妄想力 89 ● それでも何か理由があって現代でハイブリッドクラウドをやるなら、 また昔に戻って愚直に戦わなければならない ○ しかも単にオンプレだけを考えれば良いのではなく、 自分達で制御しきれないクラウド側との連携も前提にして考えなければならない ○ オンプレだけ考えればよかった昔よりも “より難しくなった”と言える
- 90. 商用ハイブリッドクラウドのための妄想力 90 ● もちろん歴史があるので、ベストプラクティス的なのはたくさんある ○ クラウド側もそうだし ● 所謂ベストプラクティス的なクラウドアーキテクチャや物理構成を取っていても、 実はこんなことがあると障害に陥るよね・・・？というのは全然ある ○ ベストプラクティスはこうやれば良い感じになるぜの道案内ガイドなだけで、 全てが網羅されたア○ティマニアではない ○ さっきの光ファイバーの例なんて教科書的なベストプラクティスには載ってない そこを自分達の構成とビジネスに照らし合わせて炙り出すのが妄想力
- 91. 商用ハイブリッドクラウドのための妄想力 91 ● キリがなくても、想像しまくって妄想しまくって、 あんなこともあるかも？こんなこともあるかも？と掘り出す ● その上で、その障害の可能性と影響度を勘案して、対策を取るかどうかを考える ● 重要なのは、妄想した障害パターンに対して一度は考えてみること ○ そもそも考えない ○ キリがないから考えない ○ 出したはいいけど考えない
- 94. 今回の事例における技術要素の紹介 94 ● ではある程度の変数を考えながら障害系を意識するとなると・・・？ ○ 大別して以下2つに分けて考えらえられる ○ NWの可用性 ○ アプリケーションの可用性 ● 今回のケースの場合、SPoFを徹底的に排除したかった ○ クラウド側は原則マルチリージョンな構成にしたい
- 95. 今回の事例における技術要素の紹介 95 ● GCPの場合、ベースとなるVPCはNW的な可用性としてそもそもマルチリージョン ○ VPNは原則リージョナル(マルチゾーン) ○ 当然、トンネルを2本以上はる必要はある ■ 単一リージョンに2本以上はってリージョナル ○ それぞれのリージョンに対してVPNを2本以上(合計:最低4本) あればマルチリージョンなVPN経路を構成できる 先ほどの構成図だと真ん中のこの部分
- 96. 今回の事例における技術要素の紹介 96 ● これで”経路”としてはマルチリージョン冗長にできる ● このままでは障害時の切り替えに対応できない ● BGPによる柔軟で高速な切り替え
- 97. 今回の事例における技術要素の紹介 97 ● VPNはVPCに入りこむ形になるので、アプリケーションを どのようにホスティングするかも考える ○ GCPの場合、GCFやCloudRunは気軽に使えて良いが、VPCネイティブではない ○ サーバーレスVPCコネクタが必要 = 障害点を増やすことにつながる ○ オンプレ側からのインバウンド通信に対応できない
- 98. 今回の事例における技術要素の紹介 98 ● GKEの場合はVPCネイティブに稼働させられる ○ k8sの知識を活かせるので運用も、まぁやりやすい ○ Autopilotを前提にすることでフルマネージドにやれるとなお良し ■ もちろん要件次第ではあるが、よほど柔軟にやりたいケースでもなければ、 Autopilotに よってk8sとしての強力なオーケストレーション能力は享受しつつノード管理などの面倒 ごとは任せちゃう ○ 参考: https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview?hl=ja
- 99. 今回の事例における技術要素の紹介 99 ● GKEの場合もリージョナルではあるが、マルチリージョンには簡単にはやれない ○ 方法としていくつか ○ Multi Cluster Ingress ○ Multci Cluster Service ○ Anthos Service Mesh
- 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に なってしまうので外部から扱えない ○ 不採用
- 102. 今回の事例における技術要素の紹介 102 ● 恐らく大体のハイブリッドクラウドの場合、オンプレ側とクラウド側のプロトコルは HTTPSに限らない はず ○ 悪いけどそれに限るなら別にインターネット経路を辿ったって良いのでは？ ○ もちろん意図してそうまとめることも一案だとは思うが ● そうなったときに途端にマルチリージョンな構成は取りづらいのが現在のクラウド
- 103. 今回の事例における技術要素の紹介 103 ● 普通にGCPとしての内部LBを使うのは？ ○ L4ロードバランサの場合、マルチリージョンな LBにできるのは外部LBのみ ○ 内部LBの場合、シングルリージョンになってしまう
- 104. 今回の事例における技術要素の紹介 104 ● つまり、VPCインターナルかつマルチリージョンな冗長性を持たせたアーキテクチャ をマネージド 前提で構築することは現状のGCPでは不可能 ○ 少なくともGKE+αでは無理(誰か何か良い方法を知っていたら教えてください) ● 外部公開なGKEのマルチリージョンなHA構成はサポートされているし、 ベストプラクティスもあるが・・・ ○ 残念ながら内部公開= VPCインターナルなのはまだまだ発展途上
- 105. 今回の事例における技術要素の紹介 考えうる有効策 105 ● 大前提としてNWでマルチリージョンなダイナミックルーティングを実現させる ● そうやってNW的な冗長経路を担保した上で、 GCPのCloudDNSルーティングポリシー&ヘルスチェックを併用 ○ 名前解決を用いたフェイルオーバーパターンということ ○ 公式ガイド: https://cloud.google.com/dns/docs/zones/manage-routing-policies ○ 公式ブログ: https://cloud.google.com/blog/ja/products/networking/introducing-automated-failover-for-private-workloads-using-cloud- dns-routing-policies-with-health-checks ●
- 106. 今回の事例における技術要素の紹介 考えうる有効策 106 ● 内部利用のためのプライベートゾーンを作っておく ● そのゾーンに対するAレコードとして、Failover Policyを持たせる ○ Primary系のClusterのServiceにヘルスチェックをかけておく ○ 原則的に名前解決結果はそちらになる ○ 障害に陥ったらSecondary側に名前解決結果が切り替わる感じ ● GEO Policiesという形でより近いリージョンに繋がるように名前解決結果を変えることも可能 ● ただし今回の例のように万が一の際に別リージョンに逃げれたらそれで良いっていう時は、 Failover Policies で十分
- 107. 今回の事例における技術要素の紹介 考えうる有効策 107 ● GEO Policiesという形でより近いリージョンに繋がるように、 名前解決結果を変えることも可能 ● ただし今回の例のように万が一の際に 別リージョンに逃げれたらそれで良いっていう時は Failover Policies で十分
- 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
- 110. 今回の事例における技術要素の紹介 考えうる有効策 110 ● このままではオンプレ側から名前解決ができない ● CloudDNSの受信サーバーポリシーを使ってVPCインターナルな名前解決を行える DNSエンドポ イントを作成しておく ○ そこに対して名前解決させてあげれば OK ○ 参考: https://cloud.google.com/dns/docs/server-policies-overview?hl=ja#dns-server-policy-in
- 111. 今回の事例における技術要素の紹介 111 # 受信サーバーポリシー作成 gcloud dns policies create your-resolver-forwarder --description=from-onprem --networks=your-vpc --enable-inbound-forwarding
- 112. 今回の事例における技術要素の紹介 考えうる有効策 112 ● ここまで書いてアレなんだけど、 このRoutingPolicy&HealthCheck機能はPreview状態 ○ 非常に残念だが・・・まだGAされていない ● というわけで商用で使うのはオススメしない ● あとこれ最近試していたんだけど一部の通信が通らなくてまだうまくいってない ...
- 113. 今回の事例における技術要素の紹介 ならどうする？ 113 ● 今回、単純に障害時に別リージョンに逃げられば良い だけ (フェイルオーバーでOK) ● Armadillo内部で各GKEクラスターのServiceに対してヘルスチェックをかけて それが落ちたらトンネルを落とす デーモンコンテナを稼働させる ○ トンネルが落ちればBGP Keepaliveも当然落ちるのでルートが切り替わって、 セカンダリの別リージョンに繋がる ○ CiscoでいうIP SLA Object Trackingのイメージ ● クラスター横断でActive-Activeで動けるアプリケーションの形としておきつつ、 途中で何があっても帰りの通信が届く形を作り上げる
- 114. 今回の事例における技術要素の紹介 GCP Autopilot環境におけるシングルリージョン環境でのダウンタイム軽減策 114 ● Autopilotの場合、フルマネージドなわけだが、 たまにメンテナンスが入る ● その間、何かしらのダウンタイムが発生してしまう可能性がゼロではない ● その度に前述の仕組みフェイルオーバーされるのも面倒 ○ してもいいけど、その程度でっていう
- 115. 今回の事例における技術要素の紹介 GCP Autopilot環境におけるシングルリージョン環境でのダウンタイム軽減策 115 ● サージアップグレードとPodDisruptionBudgetの併用で メンテナンス時においてもサービス機能としてのダウンタイムをかなり軽減 できる ○ 順次、ノードのアップグレードなどが入ってもシーケンシャルに実行され、 かつ、Podの最低数が保たれたままになるので、 特定時間でPodが全滅することがない= 事実上のダウンタイム発生しない ● サージアップグレードはAutopilotの場合デフォルトで設定されているので あまり意識しなくてもOK ● 参考: https://cloud.google.com/blog/ja/products/containers-kubernetes/introducing-surge-upgrades-for-anthos-gke?hl=ja
- 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"
- 118. 今回の事例における技術要素の紹介 Armadilloの下準備 118 ● 作成したイメージはネットワーク経由でインストールさせることも可能 ● さらにオブジェクトストレージなどを併用して簡単に DFUできる仕組みも整えると良し # 自前のどこかに独自ビルドしたカスタムイメージをおいて、そこからダウンロードして書き込む $ swupdate -d '-u http://your.image-publisher.io/update-kernel.swu' # 公式的に提供されている最新イメージを書き込む $ swupdate -d '-u https://download.atmark-techno.com/armadillo-iot-g4/image/baseos-x2-latest.swu'
- 119. 今回の事例における技術要素の紹介 119 ● 当然ながらモニタリングも意識しなければならない ○ クラウド側はまぁGCPであればCloudLoggingにログは集約されるし、 CloudMetricsでメトリクスを集めたりアラーティングは簡単に可能 ■ AWS も CloudWatchで同様 ● ビットキーの場合、全面的にDatadogを採用 ● オンプレ側を忘れてはならない
- 122. 今回の事例における技術要素の紹介 122 ● オンプレはこれ、クラウドはあれ、というようにツールを分けるのも一案 ○ 例えばDatadogとかだとどうしても物理基盤の監視が弱い ○ できはするけど SNMP Trapを操れないのが痛い ○ 物理的な故障に気付きづらい ○ ただし大体の機器はSNMP Trapに頼らず故障に気づく方法がないのが実情
- 123. 今回の事例における技術要素の紹介 123 ● GCP側はさることながら、オンプレ側も Datadogに収集させる ● Datadog AgentがSNMPをサポートしているので、 それを使ったNW機器からのメトリクス収集が可能 ○ クラウドもオンプレも統合的にモニタリング /アラーティングさせられる しかし、SNMP Getはできても、 Trapを受け止めることはできない・・・ HW障害に気づきづらい
- 124. 今回の事例における技術要素の紹介 124 ● Armadillo内部でsnmptrapdを動作させ、そのTrapの内容を示すログデータを プッシュさせることでHW障害に気づきやすくする i. VRRPやルーティングテーブルのトポロジ変化なども Trapで捕まえられる ii. Pipelineの中でGrok Parserを使ったり、 Generate Metricsさせることで任意データに変換して可視化やアラーティングに流用
- 125. 今回の事例における技術要素の紹介 125 ● 同じサービスを提供しているコンポーネントとして捉えるのであれば、 やはり一つの監視基盤でまとめあげたほうが嬉しいだろう、と判断 ○ 例えば、オンプレ用に Zabbixを採用したとしよう (対NW機器なら非常に便利) ○ 何かしらの障害やらチーム異動があった時に本件に関わるエンジニアが ゼロから覚え直さないといけないのはキツい = 学習コストが発生する ○ クラウド側でDatadogを使っていて、仮にオンプレが入ってくるこちらでも Datadogを使っているのなら、 同じ感覚で扱える = すぐに対応開始できる
- 126. 如何に妄想するか 126
- 129. 如何に妄想するか 物理的に寝る 129 ● 数日経って設計を見直すとアラが目に付く(みなさんも経験あると思うが) ● 神エンジニアならまだしも、私を含め凡人が 1日で作った設計はクソofクソ ● 原則、ローマは1日して成らない ● とにかく時間を置いて、新鮮な目で要件や設計を見直すことをセクション毎に繰り返す ○ クラウドのxxの部分 / オンプレのNWのこの部分 / こういう障害パターンのときetc.
- 130. 如何に妄想するか 設計を寝かせる 130 ● ほとんど物理的に寝ることと同義なのだが ● 完成した！って思った設計、ちょっと待て！1ヶ月寝かせよう ● その1ヶ月後にまた見直す、誰かに説明してみる(重要) ○ あれ・・・？ これ本当にこれでいいんだっけ・・・？ こんなこと/あんなことも有り得ない・・・？ ってなる ● これで熟成が進んでさらに悪い箇所が炙り出されて全体的に良くなる。
- 132. 現実と理想のギャップを埋める 132
- 133. 理想と現実のギャップを埋める 133 ● お遊びのハイブリッドクラウドは楽勝 ● 金さえかければ正常系のハイブリッドも楽勝 ● でも商用という点での可用性を持ったハイブリッドクラウドは難しい
- 134. 理想と現実のギャップを埋める 134 ● 現実と理想の線引きをせにゃならん ● ハイブリッドクラウドの可用性はマジでコストに直結 する ○ 僕たちの最強のハイブリッドクラウドができたぞ！ ○ それはお客様に本当に価値をもたらせられるモノなの？
- 135. 理想と現実のギャップを埋める 135 ● そして後戻りできない ● クラウドならば、あとで構成を見直してコスト削減・・・ができるけど、 物理が絡むオンプレ側はそうもいかない ○ 一度導入したら、3-5年は間違いなく同じものを使い続ける ことになる ● 数年間、その無駄なコストをかけた鈍重な構成に付き合い続けなければならない
- 138. 理想と現実のギャップを埋める 138 ● ハイブリッドクラウドを実装するに当たって他にも選択肢はあった ● しかし、コンセプトに照らし合わせて考えると要件を満たさないことが多い ○ GCP Anthos Clusters on bare metal ○ 専用線(InterConnect) ○ 閉域網 ○ 各社のマイクロサーバー ○ マルチ経路な専用NW機器 ○ ※これらは一部の例で、実際にはもっとたくさんの選択肢と取捨選択がありました
- 139. 理想と現実のギャップを埋める 139 ● Anthos Clusters on bare metal の可能性 ○ オンプレ側でマネージドなk8sを動かしてGCPから管理できる ○ めちゃくちゃ便利！本来なら面倒なオンプレ側のk8sをマネージドに扱える ● 不採用の理由 ○ 要求スペックが高く、それを満たすための機器を買おうとするとコストが嵩む ○ オンプレ側でゴリゴリにk8s動かしたいほどのワークロードはない ○ そんな鈍重な構成にしたくない
- 140. 理想と現実のギャップを埋める 140 ● 中規模〜大規模なハイブリッド構成をやるなら専用線を導入すべき ○ AWS: DirectConnect ○ GCP: InterConnect ○ Azure: ExpressRoute ● 圧倒的に速くて安定的 ● そういう規模のケースなら自分でもそうするし、過去そうした ○ が、今回の用途には合わない
- 141. 理想と現実のギャップを埋める 141 ● しかし、とにかくイニシャルコストもランニングコストもかかる ○ 最低でも月額10数万は覚悟すべき ● 障害や数ヶ月に一度のメンテナンスがあるので マルチキャリアな専用線を導入をすべき ○ となると、さらにランニングコストは倍増する ● 導入まで手間もかかるしリードタイムも必要 ● 津々浦々に増えていく個々のお客様向けにこれやるの？？？？
- 142. 理想と現実のギャップを埋める 142 ● モバイル回線 + 閉域網を使うケース ○ 特に何も構成せずともSIM挿すだけでGCPとローカル通信が可能になる ○ VPNの管理/メンテナンスコストを低減可能 ○ おそらく、今回のような他拠点・不特定多数のハイブリッドクラウド構築でもない限りは、正直 閉域網を使った方が楽だと思う
- 143. 理想と現実のギャップを埋める 143 ● 閉域網を採用しなかった理由 ○ ランニングコストが高い ○ フレキシビリティが低い ■ ベンダーが設定したいくつかのオプション以外のことはできない ○ スケーラビリティが低い ■ 何かしらトラフィック的に限界を迎えてもなかなか上げられない ○ アジリティが低い ■ 調達までのリードタイムが長く発注かけてから 1-2ヶ月かかってしまう
- 144. 理想と現実のギャップを埋める 144 ● 専用線が悪いわけじゃない/ 閉域網が悪いわけじゃない ○ 間違いなく高速で安定的だし、一度導入してしまえば後は楽 ○ 管理や責任をこちらで持つ必要がない ○ お金さえ出せば、東西冗長もしてくれるので可用性も引き上げられる ○ しかしながらモノの良さと、ビジネスと照らし合わせた上での良さは異なる ○ 今回のケースだと合致しなかっただけ
- 145. 理想と現実のギャップを埋める 145 ● 専用NW機器の検討も当然してみた ○ Ciscoでいえば C1111-8PLTELA とかなら有線GbEもLTEも使える ○ 各社少なからず似たようなのがある ● 最初に検討したのがこれ系だったのが、 万が一の潰しが効かない ○ そりゃIPsecのHWオフロード効かせるようなスループットやら NAT性能やらが 欲しいならこういう系を使うべきだが今回はそこまでのパフォーマンスは不要 ○ だとすれば、汎用性が高い方を選びたかった= LinuxのNW機器化 ● 調達リードタイムが長くなりがち ○ 上述のC1111-8PLTELAだと納期約10ヶ月。。。
- 146. 理想と現実のギャップを埋める 146 ● 各サーバーベンダーからマイクロサーバーというものがリリースされている ○ 20万〜ぐらいの安さで両手サイズぐらいの小さなサーバーが手に入る ○ コンシューマー向けのIntel NUCをひとまわり大きくした感じのやつ ● こちらの方が潰しが効く ○ が、今後のビジネス展開を考えた時に最小構成であってもオーバースペック ○ 絶対的には安いけど、我々のビジネスを考えた時には相対的に高い ○ お客様への価格的訴求力を弱めてしまう
- 147. 理想と現実のギャップを埋める 147 ● エンジニアならより良いものを！よりパフォーマンスが出るものを！となりがち ● しかし、営利企業としてプロダクトを提供する以上、 ビジネスを考えた設計や開発をしなければならない ● そうなった時に前述のサーバーや Anthosや専用線や閉域網は合わなかった ○ どれもモノとして悪いわけじゃない ○ 単に今回の要件や用途に合わないだけ
- 148. 理想と現実のギャップを埋める 148 ● ビジネスラインを見誤った結果のアーキテクチャからくるコストアップを お客様に転嫁するのは間違っている 、と断言したい ○ 自己満を押し付けるなっていうこと ○ もちろんだからと言って身銭を切って安く早く提供する・・・というのも違う ● 最強が最善とは限らない
- 149. 理想と現実のギャップを埋める 提供プランとお客様自身の選択できる自由を 149 ● High Availabillity プラン: 年間数分も止めたくないお客様向け ○ 完全なマルチリージョン構成による High Availabillityな環境 ● Regular プラン: 年間数十分ぐらいのダウンタイムなら許容できるお客様向け ○ 滅多にヤバいことは起きないよねっていうことでリージョナル構成が前提 お客様の事情に応じて安いプランでも高いプランでも選択できるように
- 150. お伝えしたいこと 150 ● ハイブリッドクラウドには妄想力が必要不可欠 ● 寝よう / 寝かせよう ● 最強は最善ではない 頭の片隅にでも置いておいていただけると、現実的なハイブリッドクラウド設計ができる・・・かも。
- 151. 151 おわり
- 152. 152 諦めたこと ● 物理機器内部の耐障害性 ○ 高価なNW機器やサーバーでは当たり前のような各コンポーネントの二重化は捨てた ○ それもやり出すと相当オーバースペックな機器になり、コストが嵩む ○ どうせメモリやMBが故障したら死ぬ ○ “壊れる”ことを前提にする ■ 別の何かで冗長性を保ってダウンタイムが実質数十秒なら問題ないよね？理論 ■ あえて安価で交換しやすい機器たちにすることで、すぐに誰でも交換できるようにする ■ 壊れてなんぼ、壊れたってケーブル繋ぎかえるだけで終わるよ〜のスタンスで臨む ○ この辺は拡充してあとでどこかに入れ たい。 妄想した障害パターンの中で、何に対 策して何を諦めたのか？の話