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

More Related Content

Similar to [Cloud Native Days Tokyo 2022] たまにはオンプレもいいぞ? GKE と Armadillo IoT で実現する ハイブリッドクラウド

Hyperledger Fabric Private Chaincodeについて
Hyperledger Fabric Private ChaincodeについてHyperledger Fabric Private Chaincodeについて
Hyperledger Fabric Private Chaincodeについて
Hyperleger Tokyo Meetup
 
Big Cloud Fabric製品紹介とOpenStack Neutron Plugin 実装概要
Big Cloud Fabric製品紹介とOpenStack Neutron Plugin 実装概要Big Cloud Fabric製品紹介とOpenStack Neutron Plugin 実装概要
Big Cloud Fabric製品紹介とOpenStack Neutron Plugin 実装概要
Shohei Yoshimoto
 
[Cloud OnAir] Anthosで実現するハイブリッドクラウド 〜 GKE On-Prem編 〜 2019年8月29日 放送
[Cloud OnAir] Anthosで実現するハイブリッドクラウド 〜 GKE On-Prem編 〜 2019年8月29日 放送[Cloud OnAir] Anthosで実現するハイブリッドクラウド 〜 GKE On-Prem編 〜 2019年8月29日 放送
[Cloud OnAir] Anthosで実現するハイブリッドクラウド 〜 GKE On-Prem編 〜 2019年8月29日 放送
Google Cloud Platform - Japan
 
Modernization of IT Infrastructure by Microsoft Azure
Modernization of IT Infrastructure by Microsoft AzureModernization of IT Infrastructure by Microsoft Azure
Modernization of IT Infrastructure by Microsoft Azure
Takeshi Fukuhara
 
モバイルオンラインゲームでの大規模観戦とチート対策 〜自社製リアルタイム通信システム「WSNet2」の事例〜
モバイルオンラインゲームでの大規模観戦とチート対策 〜自社製リアルタイム通信システム「WSNet2」の事例〜モバイルオンラインゲームでの大規模観戦とチート対策 〜自社製リアルタイム通信システム「WSNet2」の事例〜
モバイルオンラインゲームでの大規模観戦とチート対策 〜自社製リアルタイム通信システム「WSNet2」の事例〜
KLab Inc. / Tech
 
CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜
CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜
CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜
Masaya Aoyama
 
Modernization of Factory Automation with Elixir based systems and communities
Modernization of Factory Automation with Elixir based systems and communitiesModernization of Factory Automation with Elixir based systems and communities
Modernization of Factory Automation with Elixir based systems and communities
Yutaka Kikuchi
 
「クラウド移行をめぐるウソ・ホント」 オンプレのVMwareからの切替は大変?P2V2Cの具体的な事例を紹介
「クラウド移行をめぐるウソ・ホント」 オンプレのVMwareからの切替は大変?P2V2Cの具体的な事例を紹介「クラウド移行をめぐるウソ・ホント」 オンプレのVMwareからの切替は大変?P2V2Cの具体的な事例を紹介
「クラウド移行をめぐるウソ・ホント」 オンプレのVMwareからの切替は大変?P2V2Cの具体的な事例を紹介
富士通クラウドテクノロジーズ株式会社
 
「クラウド移行をめぐるウソ・ホント」 オンプレのVMwareからの切替は大変?P2V2Cの具体的な事例を紹介
「クラウド移行をめぐるウソ・ホント」 オンプレのVMwareからの切替は大変?P2V2Cの具体的な事例を紹介「クラウド移行をめぐるウソ・ホント」 オンプレのVMwareからの切替は大変?P2V2Cの具体的な事例を紹介
「クラウド移行をめぐるウソ・ホント」 オンプレのVMwareからの切替は大変?P2V2Cの具体的な事例を紹介
富士通クラウドテクノロジーズ株式会社
 
VisualStudioでマイコンボードを制御する
VisualStudioでマイコンボードを制御するVisualStudioでマイコンボードを制御する
VisualStudioでマイコンボードを制御する
Tadahiro Kimura
 
DXを進めるための5Gの基礎知識
DXを進めるための5Gの基礎知識DXを進めるための5Gの基礎知識
DXを進めるための5Gの基礎知識
masaaki murakami
 
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
NTT DATA Technology & Innovation
 
ビットキーのIoT基盤におけるAWS IoT Rule Action 活用
ビットキーのIoT基盤におけるAWS IoT Rule Action 活用ビットキーのIoT基盤におけるAWS IoT Rule Action 活用
ビットキーのIoT基盤におけるAWS IoT Rule Action 活用
Ryo Sasaki
 
WeDX Flow Hands-on
WeDX Flow Hands-onWeDX Flow Hands-on
WeDX Flow Hands-on
Jingun Jung
 
大学研究室レベルでLocal 5Gを導入するための手法の考察
大学研究室レベルでLocal 5Gを導入するための手法の考察大学研究室レベルでLocal 5Gを導入するための手法の考察
大学研究室レベルでLocal 5Gを導入するための手法の考察
Yutaka Kikuchi
 
どっちの VS ショー / 伝統の Visual Studio 2019、人気の Visual Studio Code
どっちの VS ショー / 伝統の Visual Studio 2019、人気の Visual Studio Codeどっちの VS ショー / 伝統の Visual Studio 2019、人気の Visual Studio Code
どっちの VS ショー / 伝統の Visual Studio 2019、人気の Visual Studio Code
Takashi Okawa
 
MEC (Mobile Edge Computing) + GPUコンピューティングについて
MEC (Mobile Edge Computing) + GPUコンピューティングについてMEC (Mobile Edge Computing) + GPUコンピューティングについて
MEC (Mobile Edge Computing) + GPUコンピューティングについて
VirtualTech Japan Inc.
 
Hybrid cloud fj-20190704_final
Hybrid cloud fj-20190704_finalHybrid cloud fj-20190704_final
Hybrid cloud fj-20190704_final
Kei Furusawa
 
DevOps with GitLabで始める簡単DevOps
DevOps with GitLabで始める簡単DevOpsDevOps with GitLabで始める簡単DevOps
DevOps with GitLabで始める簡単DevOps
富士通クラウドテクノロジーズ株式会社
 
AWSにおけるIaCを活かしたTerraformの使い方2選! ~循環型IaCとマルチクラウドチックなDR環境~ (HashiTalks: Japan 発...
AWSにおけるIaCを活かしたTerraformの使い方2選! ~循環型IaCとマルチクラウドチックなDR環境~ (HashiTalks: Japan 発...AWSにおけるIaCを活かしたTerraformの使い方2選! ~循環型IaCとマルチクラウドチックなDR環境~ (HashiTalks: Japan 発...
AWSにおけるIaCを活かしたTerraformの使い方2選! ~循環型IaCとマルチクラウドチックなDR環境~ (HashiTalks: Japan 発...
NTT DATA Technology & Innovation
 

Similar to [Cloud Native Days Tokyo 2022] たまにはオンプレもいいぞ? GKE と Armadillo IoT で実現する ハイブリッドクラウド (20)

Hyperledger Fabric Private Chaincodeについて
Hyperledger Fabric Private ChaincodeについてHyperledger Fabric Private Chaincodeについて
Hyperledger Fabric Private Chaincodeについて
 
Big Cloud Fabric製品紹介とOpenStack Neutron Plugin 実装概要
Big Cloud Fabric製品紹介とOpenStack Neutron Plugin 実装概要Big Cloud Fabric製品紹介とOpenStack Neutron Plugin 実装概要
Big Cloud Fabric製品紹介とOpenStack Neutron Plugin 実装概要
 
[Cloud OnAir] Anthosで実現するハイブリッドクラウド 〜 GKE On-Prem編 〜 2019年8月29日 放送
[Cloud OnAir] Anthosで実現するハイブリッドクラウド 〜 GKE On-Prem編 〜 2019年8月29日 放送[Cloud OnAir] Anthosで実現するハイブリッドクラウド 〜 GKE On-Prem編 〜 2019年8月29日 放送
[Cloud OnAir] Anthosで実現するハイブリッドクラウド 〜 GKE On-Prem編 〜 2019年8月29日 放送
 
Modernization of IT Infrastructure by Microsoft Azure
Modernization of IT Infrastructure by Microsoft AzureModernization of IT Infrastructure by Microsoft Azure
Modernization of IT Infrastructure by Microsoft Azure
 
モバイルオンラインゲームでの大規模観戦とチート対策 〜自社製リアルタイム通信システム「WSNet2」の事例〜
モバイルオンラインゲームでの大規模観戦とチート対策 〜自社製リアルタイム通信システム「WSNet2」の事例〜モバイルオンラインゲームでの大規模観戦とチート対策 〜自社製リアルタイム通信システム「WSNet2」の事例〜
モバイルオンラインゲームでの大規模観戦とチート対策 〜自社製リアルタイム通信システム「WSNet2」の事例〜
 
CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜
CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜
CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜
 
Modernization of Factory Automation with Elixir based systems and communities
Modernization of Factory Automation with Elixir based systems and communitiesModernization of Factory Automation with Elixir based systems and communities
Modernization of Factory Automation with Elixir based systems and communities
 
「クラウド移行をめぐるウソ・ホント」 オンプレのVMwareからの切替は大変?P2V2Cの具体的な事例を紹介
「クラウド移行をめぐるウソ・ホント」 オンプレのVMwareからの切替は大変?P2V2Cの具体的な事例を紹介「クラウド移行をめぐるウソ・ホント」 オンプレのVMwareからの切替は大変?P2V2Cの具体的な事例を紹介
「クラウド移行をめぐるウソ・ホント」 オンプレのVMwareからの切替は大変?P2V2Cの具体的な事例を紹介
 
「クラウド移行をめぐるウソ・ホント」 オンプレのVMwareからの切替は大変?P2V2Cの具体的な事例を紹介
「クラウド移行をめぐるウソ・ホント」 オンプレのVMwareからの切替は大変?P2V2Cの具体的な事例を紹介「クラウド移行をめぐるウソ・ホント」 オンプレのVMwareからの切替は大変?P2V2Cの具体的な事例を紹介
「クラウド移行をめぐるウソ・ホント」 オンプレのVMwareからの切替は大変?P2V2Cの具体的な事例を紹介
 
VisualStudioでマイコンボードを制御する
VisualStudioでマイコンボードを制御するVisualStudioでマイコンボードを制御する
VisualStudioでマイコンボードを制御する
 
DXを進めるための5Gの基礎知識
DXを進めるための5Gの基礎知識DXを進めるための5Gの基礎知識
DXを進めるための5Gの基礎知識
 
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
 
ビットキーのIoT基盤におけるAWS IoT Rule Action 活用
ビットキーのIoT基盤におけるAWS IoT Rule Action 活用ビットキーのIoT基盤におけるAWS IoT Rule Action 活用
ビットキーのIoT基盤におけるAWS IoT Rule Action 活用
 
WeDX Flow Hands-on
WeDX Flow Hands-onWeDX Flow Hands-on
WeDX Flow Hands-on
 
大学研究室レベルでLocal 5Gを導入するための手法の考察
大学研究室レベルでLocal 5Gを導入するための手法の考察大学研究室レベルでLocal 5Gを導入するための手法の考察
大学研究室レベルでLocal 5Gを導入するための手法の考察
 
どっちの VS ショー / 伝統の Visual Studio 2019、人気の Visual Studio Code
どっちの VS ショー / 伝統の Visual Studio 2019、人気の Visual Studio Codeどっちの VS ショー / 伝統の Visual Studio 2019、人気の Visual Studio Code
どっちの VS ショー / 伝統の Visual Studio 2019、人気の Visual Studio Code
 
MEC (Mobile Edge Computing) + GPUコンピューティングについて
MEC (Mobile Edge Computing) + GPUコンピューティングについてMEC (Mobile Edge Computing) + GPUコンピューティングについて
MEC (Mobile Edge Computing) + GPUコンピューティングについて
 
Hybrid cloud fj-20190704_final
Hybrid cloud fj-20190704_finalHybrid cloud fj-20190704_final
Hybrid cloud fj-20190704_final
 
DevOps with GitLabで始める簡単DevOps
DevOps with GitLabで始める簡単DevOpsDevOps with GitLabで始める簡単DevOps
DevOps with GitLabで始める簡単DevOps
 
AWSにおけるIaCを活かしたTerraformの使い方2選! ~循環型IaCとマルチクラウドチックなDR環境~ (HashiTalks: Japan 発...
AWSにおけるIaCを活かしたTerraformの使い方2選! ~循環型IaCとマルチクラウドチックなDR環境~ (HashiTalks: Japan 発...AWSにおけるIaCを活かしたTerraformの使い方2選! ~循環型IaCとマルチクラウドチックなDR環境~ (HashiTalks: Japan 発...
AWSにおけるIaCを活かしたTerraformの使い方2選! ~循環型IaCとマルチクラウドチックなDR環境~ (HashiTalks: Japan 発...
 

More from Ryo Sasaki

[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
Ryo Sasaki
 
ゼロトラスト三銃士〜Okta x Jamf x Netskopeネタ10連発〜
ゼロトラスト三銃士〜Okta x Jamf x Netskopeネタ10連発〜ゼロトラスト三銃士〜Okta x Jamf x Netskopeネタ10連発〜
ゼロトラスト三銃士〜Okta x Jamf x Netskopeネタ10連発〜
Ryo Sasaki
 
[Okta x Jamf合同新年会] Okta Workflowsによるノーコード業務改善 〜Jamf APIを使ってMac端末情報を自動収集してみよう〜
[Okta x Jamf合同新年会] Okta Workflowsによるノーコード業務改善 〜Jamf APIを使ってMac端末情報を自動収集してみよう〜[Okta x Jamf合同新年会] Okta Workflowsによるノーコード業務改善 〜Jamf APIを使ってMac端末情報を自動収集してみよう〜
[Okta x Jamf合同新年会] Okta Workflowsによるノーコード業務改善 〜Jamf APIを使ってMac端末情報を自動収集してみよう〜
Ryo Sasaki
 
DynamoDBの初心者に伝えたい初めて触るときの勘所
DynamoDBの初心者に伝えたい初めて触るときの勘所DynamoDBの初心者に伝えたい初めて触るときの勘所
DynamoDBの初心者に伝えたい初めて触るときの勘所
Ryo Sasaki
 
OpenStackを導入・1年運用したチームの変化
OpenStackを導入・1年運用したチームの変化OpenStackを導入・1年運用したチームの変化
OpenStackを導入・1年運用したチームの変化
Ryo Sasaki
 
AWSの真髄
AWSの真髄AWSの真髄
AWSの真髄
Ryo Sasaki
 
Linux Kernel Parameter Tuning
Linux Kernel Parameter TuningLinux Kernel Parameter Tuning
Linux Kernel Parameter Tuning
Ryo Sasaki
 
Infrastructre as Ccodeの実現 - Ansibleの基本 -
Infrastructre as Ccodeの実現 - Ansibleの基本 - Infrastructre as Ccodeの実現 - Ansibleの基本 -
Infrastructre as Ccodeの実現 - Ansibleの基本 -
Ryo Sasaki
 
きっと今すぐ使えるハッシュの基礎知識
きっと今すぐ使えるハッシュの基礎知識きっと今すぐ使えるハッシュの基礎知識
きっと今すぐ使えるハッシュの基礎知識
Ryo Sasaki
 

More from Ryo Sasaki (9)

[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
 
ゼロトラスト三銃士〜Okta x Jamf x Netskopeネタ10連発〜
ゼロトラスト三銃士〜Okta x Jamf x Netskopeネタ10連発〜ゼロトラスト三銃士〜Okta x Jamf x Netskopeネタ10連発〜
ゼロトラスト三銃士〜Okta x Jamf x Netskopeネタ10連発〜
 
[Okta x Jamf合同新年会] Okta Workflowsによるノーコード業務改善 〜Jamf APIを使ってMac端末情報を自動収集してみよう〜
[Okta x Jamf合同新年会] Okta Workflowsによるノーコード業務改善 〜Jamf APIを使ってMac端末情報を自動収集してみよう〜[Okta x Jamf合同新年会] Okta Workflowsによるノーコード業務改善 〜Jamf APIを使ってMac端末情報を自動収集してみよう〜
[Okta x Jamf合同新年会] Okta Workflowsによるノーコード業務改善 〜Jamf APIを使ってMac端末情報を自動収集してみよう〜
 
DynamoDBの初心者に伝えたい初めて触るときの勘所
DynamoDBの初心者に伝えたい初めて触るときの勘所DynamoDBの初心者に伝えたい初めて触るときの勘所
DynamoDBの初心者に伝えたい初めて触るときの勘所
 
OpenStackを導入・1年運用したチームの変化
OpenStackを導入・1年運用したチームの変化OpenStackを導入・1年運用したチームの変化
OpenStackを導入・1年運用したチームの変化
 
AWSの真髄
AWSの真髄AWSの真髄
AWSの真髄
 
Linux Kernel Parameter Tuning
Linux Kernel Parameter TuningLinux Kernel Parameter Tuning
Linux Kernel Parameter Tuning
 
Infrastructre as Ccodeの実現 - Ansibleの基本 -
Infrastructre as Ccodeの実現 - Ansibleの基本 - Infrastructre as Ccodeの実現 - Ansibleの基本 -
Infrastructre as Ccodeの実現 - Ansibleの基本 -
 
きっと今すぐ使えるハッシュの基礎知識
きっと今すぐ使えるハッシュの基礎知識きっと今すぐ使えるハッシュの基礎知識
きっと今すぐ使えるハッシュの基礎知識
 

[Cloud Native Days Tokyo 2022] たまにはオンプレもいいぞ? GKE と Armadillo IoT で実現する ハイブリッドクラウド