[OpenShift.Run]エンプラもOpenshiftでプラットフォームを作りたい

エンプラもOpenShiftでプラットフォームを作りたい ~「OpenShiftという『ミドルウェア』が入ったサーバ」にしないために~ 2020-12-10 OPENSHIFT.RUN Satoshi Doi IBM Japan, Ltd.

免責事項 本セッションは個人の見解であり、 所属組織の立場、戦略、意見を代表するものではありません。 また、技術的な内容にも言及しますが、正確性を保証するものではありません。

自己紹介 転職組 IBM Japan, 2019年2月からIBM Cloud Application Services, Modernization Strategy 怖いIBMさん達 Satoshi Doi @satoshi55d Application Architect Red Hat Certified Specialist 私 ❤️OpenShift IBM製品で唯一好きなのがLiberty 最近意外とできる子なんだと気がついた (怖くない方のIBM)

エンプラの選択するOpenShift利用形態 コストの観点でまずはマルチテナントな形態を選択する場合が多い ◼ マルチテナント ◼ マルチクラスタ コスト効率: ◎ アプリ独立性: △？ コスト効率: × アプリ独立性: ◎ 利用ユーザ・アプリ 利用ユーザ・アプリ 本セッションは こちらを前提にお話します。

エンプラあるあるプラットフォーム構想 システム更改の「ついで」にふわっとプラットフォーム化を志す ◼ 出来上がるもの ◼ 作りたいもの 更改後システム「用」のOpenShift 計画的ならまだしもこれでペイするのか？ OpenShiftで様々なアプリ、サービスが稼働 更改後システムはそのうちの「一つ」 更改後システム 現実は‥ なんかDXとか推進出来るなにか プラットフォーム？ OpenShiftという『ミドルウェア』が入ったサーバ群

エンプラあるあるプラットフォーム構想
目指す姿の『共通認識』ができないままではいつまで経っても完成しない
＿＿＿＿＿＿＿＿＿＿＿＿
ヾミ || || || || || || || ,l,,l,,l 川〃彡|
V~~‘’-山┴‘’‘’“”~ ヾニﾆ彡|
/ 二ー―‘’二
ヾﾆニ┤
<'-., ￣￣
_,,,..-‐､ 〉ニﾆ|
/"''-ﾆ,‐l
l`__ニ-‐'''""` /ニ二|
| ==＝､! `＝====､l =ｌべ=|
.
| `ーﾟ‐'/
`ー‐ﾟ―'
l.=lへ|~|
|`ー‐/
`ー―― H<,〉|=|
| /
､
l|__ノｰ|
.
| ／`ー ~ ′
＼
.|ヾ.ニ|ヽ
|ｌ 下王l王l王l王lヲ｜
| ヾ_,| ＼
.
|
≡
|
`l
＼__
!、
_,,..-‘′ ／l
| ~’‘’
‐''"￣| `iｰ-..,,,＿,,,,,....-‐'''"
／ |
|
-―| |＼
／
|
|
|
| ＼
／
|
|

作る・・・・・・！
作るが・・・
今回 まだ その時と場所の
指定まではしていない
そのことを
どうかエンプラのお客様も
思い出していただきたい
つまり・・・・
我々がその気になれば
プラットフォームの完成は
10年後 20年後ということも
可能だろう・・・・・・・・・・ということ・・・・！

本日お話ししたいこと 誰も狙って無価値な基盤を作ろうなどと思っていない なぜこのようなことが起きるのでしょうか？ 「だから散々言ったのに…」 現場では問題を指摘したのに受け入れてもらえなかった？ ステークホルダー達のK8sの理解が不十分？ 彼らがK8sを理解しようともしないで現場任せにしているから悪い？ いいえ！ 「K8sがこれまでのトラディショナルなテクノロジーの考え方とかけ離れて おり、見るべき世界・景色が違っていることに気づかないから」 と考えた方が建設的ではないでしょうか？ 本セッションでは、 ① ステークホルダーとの認識齟齬を把握し、 ② そんな彼らとどのようにプラットフォームを作っていけば良いのか をK8s/OpenShiftの機能も絡めつつご紹介します。 お互いの見る世界・景色を一致させて 『共創』するために

ステークホルダーとの認識の違いを把握する

ステークホルダーの定義 それぞれの立場、それぞれのフェーズでステークホルダーは様々 本セッションでのステークホルダーとは ◼ 社内: プロジェクトマネージャ、チームリーダ、 他チーム（基盤チーム、アプリチーム） 営業、コンサル ◼ 顧客: 担当者、エグゼクティブ といった、K8s / OpenShift導入に関わる重要な意思決定や設計を行うキーマンを指します。 各自のステークホルダーを思い浮かべながらお聞きください。

我々が思うKubernetes/OpenShift 「プラットフォームを作るためのプラットフォーム」 これ単体で何ができるわけではなく、プラットフォームの志向性が大事

大部分のステークホルダーが思うKubernetes/OpenShift 違 う の だ ‼ だあなそ ろりんこ うゃのに がし違 ！ねい ぇも これまでは に Applicationサーバ WAR をデプロイしてた これからは に OpenShift をデプロイする！ コンテナ

OpenShiftはミドルウェアじゃないと思うの… 『ミドルウェア』として捉えて単純に機能だけを見てしまう 確かにOpenShiftってやつは 『機能』が豊富だし色々と 出来るらしい。 高機能なミドルウェアってことかな。 これらを使って何を成すか、が大事なんですけど…

「基盤」コストに目がいくのもわかるけど… 「基盤」の集約という一見わかりやすそうなメリットだけを見てしまう ああ、なるほど。 いつもの構成をOpenShiftに集約 できるんだね。 基盤コスト圧縮できてこれは良いね。 いつもの構成 （よくあるWeb・AP・DBの3層構成） LB アプリ利用者 Web + Application Server DB Server そこをメインの価値にするともったいないのでは… そもそもTCOで見てちゃんとペイ出来るか見積もった？

見てる世界の違いで発生する誤ったスコープ・ゴール設定 OpenShiftによってプラットフォーム を構築し、その上で複数のアプリケー ションを迅速に展開出来るようにして いきましょう！ プラットフォーム （自立分散 > 中央集権） うんうん、そうだね。 でも予算も限られているわけだから先ずは 更改するシステムをターゲットして作って、 そこから『段階的に』大きくしていこう。 共通基盤構想はその後で考える でも良いじゃないか。 共通基盤 (自立分散 < 中央集権)

長年培ってきた考えを覆すのは至難の技 中央集権的な「共通基盤」をしっかりと「管理」してきた歴史 ◼ エンタープライズは歴史的に、SOA基盤のような中央集権的システム管理を行ってきた ➢ トップダウンで統制をとることで大規模なシステムを安全に効率良く管理する仕組みとして機能した 長年彼らが実践し、成功体験を重ねてきた考えに基づいている しっかりと管理すればなんであれ使うことができる（と思っている） 更改後システム 新規アプリ プラットフォーム？ だからアプリからインフラまでしっかりと中央集権的に管理したがる その結果出来上がるOpenShiftというミドルウェアの入ったサーバ群 既存の共通基盤より手のかかる中央集権管理OpenShift

これだからエンプラは…。そう思って諦めてませんか？ 『あなたにKubernetesは必要ですか？』 『多分あなたにKubernetesは必要ない』 『Kubernetes の導入時に考えるべきこと』 ぐうの音も出ないほど正しい。 それ相応のビジネスプランがあり、そのためのあるべき 組織や文化を醸成、それでこそK8s/OpenShiftの 真価が発揮できる。 現場じゃどうしようもないよ…。 トップダウン DXへ導くビジネスプラン 確かに、彼らのマインドセットを変えるの は一朝一夕では難しい。 あるべき組織・文化の醸成 K8sの真の価値とは？ しかしながらそれを認めた上で、現場で できることはないのか？ 彼らのマインドセットが醸成された未来を 見据えて無駄にならないプラットフォーム を作ることはできないのか？ ？？？？ ボトムアップ ボトムアップでできることだってあるはず

ステークホルダーと何をもってすり合わせていくべきか？

まずちゃんと『設計』しませんか？ 「設計」としてアウトプットするものも変えていかなければならない 現場としても既存の設計「しか」しておらず、K8sというプロダクトの暗黙の定義に頼っているところがあるのではないか？ ◼ これまでやってきた設計内容 ・アプリ設計 ・インフラ設計 ・ミドルウェア設計 ・非機能設計 ・運用設計 ・環境定義書 etc. 設計書の名前やフォーマットはなんでも良いが、その中で 以下のような設計項目をプラットフォーム設計としてきちんと含めているか？ 1. 2. 3. 4. プラットフォームとして目指す姿を定義する 責任境界を明確にする 共有と分離設計を行う 生産性と管理性のバランスを取る 「設計」としてステークホルダに説明するなら彼らの土壌で等しく会話ができるはずではないか？ そして、例え彼らに「今は」理解されなくても、理解された時に作り直ししなくても良いように「準備」できるのではないか？ そういった観点で、設計項目という名のボトムアップでステークホルダーとすり合わせていくべき項目をいくつかご紹介します。

プラットフォームとして目指す姿を定義する ◼ 「プラットフォーム」としてのVIEW ◼ 「基盤」としてのVIEW 利用者 サーバ構成 Master * 3 OS: RHCOS CPU: 8 core Memory: 64 GB ネットワーク構成 ストレージ構成 システムB システムA システムX システムY App App App App App App App App App App App App App App App App ミドルウェア構成 Internal LB 運用・監視設計 可用性設計 表裏一体 提供 バックアップリカバリ etc. External LB Infra * 3 OS: RHCOS CPU: 4 core Memory: 64 GB Worker * 3 OS: RHCOS CPU: 8 core Memory: 64 GB 利用 & Feed Back 提供側 提供 サービス機能・共有知 インフラリソース (アプリランタイム、標準設計) (CPU、メモリ、ネットワーク、ストレージ、etc.) 連携 クラスタ管理者・インフラ管理者 必ず作る、とても大事な設計資料だけど、これだけでは足りないのでは？ ➢ 基盤をどのように利用者に使ってもらうか？の定義がされていない。 利用側 機能整備・標準化担当者 プラットフォームとして目指す姿やコンセプトを定義する。 ➢ 如何に「管理する」か、ではなく如何に「運営する」か。

責任境界を明確にする 責任境界を適切に定義しなければ中央集権管理される巨大なモノリシックシステムになる 「曖昧な責任境界」、「利用者に許容する少なすぎる裁量」が不要な組織間コミュニケーションを増大させモノリシックを作る。 ◼ 避けたいロール設計（設計しないと大体こうなる） ◼ 最低限考えておきたいロール設計 利用者がどこまで自由にできるか？をまず決める。 利用者内でのロール設計は利用者に移譲。 利用側 提供側 インフラ、クラスタ管理者、標準化担当など、 組織や運用体制を踏まえて決定する。 何でもかんでも「管理者」という曖昧なロールが行う前提 ➢ こうなってしまうと何を頑張ってもモノリシックまっしぐら どのロールに、何を、どこまで許容するか明確にする ➢ プラットフォームの目指す姿に合わせてきちんと設計する (もちろん技術的にどこまで権限分離できるか知ることも重要)

共有と分離設計を行う マルチテナント設計は必須。最初から意識して設計する プラットフォームの共有には必要な機能を使って適切に分離しないと実質不可能 直近プラットフォームに載せるアプリが一つだとしてもやっておかないと後から別なアプリが載る時の影響が大きくなる ⚫ Namespaceのデフォルト設定 ⚫ Network Policy 左の分離設定は都度設定していては管理者の負荷が高まるし 初期設定ガバガバはまずい。デフォルト値大事。 適切なネットワークセキュリティ設計による分離。 Namespace A allow Network Policy Project Template allow DB A Deny Deny allow Namespace B Network Policy Open Policy Agent allow DB B ⚫ Quota インフラリソースの適切な割り当て。リソース不足の影響を分離。 Namespace A Quota Limit Range Limit Range Limit Range Limit Range Namespace B Quota OpenShiftだとNamespace作成時に作られるデフォルトリソースを設定しておける Open Policy Agentをこの辺の管理に使っても良いかもしれない ⚫ 変更プロセスはとても大事だけど成熟度に合わせて柔軟に Network Policy, Quotaの利用者からの変更依頼発生時の変更 プロセスは導入先の組織・文化の成熟度に合わせて柔軟に。 ただし、変更に数週間、数ヶ月かかります、みたいな変更プロセスに なると全てが台無しなので上記のデフォルト設定も含めてしっかりと すり合わせる。 （頑張りどころだけど、流石にこの辺は組織や文化からは逃げられないか…）

共有と分離設計を行う OpenShiftで考えてくれているマルチテナント機能 OpenShiftでは最初からマルチテナントを志向して用意してくれている機能があるので必要に応じて使う。 特にありがたいのが、「ログ基盤」と「監視基盤」 ⚫ ログ基盤 Elasticsearch & SearchGuard マルチテナントなEFKスタックが用意されている。 ⚫ 監視基盤 User Workload Monitoring 利用者が使うPrometheus管理Operatorが4.6で遂にGA！ Elasticsearch User Workload Monitoring Namespace A ログデータ Namespace B ログデータ Watch Namespace A allow Namespace A 利用者 deny allow Namespace B 利用者 Namespace毎にログ保有期間も調整できるので適宜設計する。 クラスタ管理者しか見れないけど利用者もみたいログがあるか？なども検討。 Prometheus Rule Namespace B Service/Pod Monitor Prometheus Rule Service/Pod Monitor それぞれのCustomResourceをapplyすることでPrometheusに設定してくれる。 • Service/PodMonitor Prometheus Targetの設定 • PrometheusRule Prometheus Ruleの設定 CustomResorceを経由して一つのPrometheusを共有する仕組み。 （Alertmanagerは適宜全体設計しないとダメか。）

共有と分離設計を行う OpenShiftはプラットフォームを構成する一つの要素にすぎない 「OpenShift」のマルチテナント設計に注力しがちだが、OpenShiftを取り巻く周辺要素も忘れてはならない。 ⚫ 資産管理 資産管理 マルチテナントなプロダクトの選定と管理体系の設計 Gitlab Container Registry 運用 ネットワーク バッチ管理 OpenShiftクラスタ LB 運用管理 特定アプリにターゲットしてLBの性能やネットワーク帯域を見 積もると死ぬ。意外とこの辺ボトルネックになりやすい。 ⚫ 永続化 クラスタの外にDB置くなら共有か独立かの選択。 PVは大体NFSなのでここも共有か独立かの選択。 ⚫ 運用 永続化 DB ⚫ ネットワーク 結構マルチテナント設計で見逃しがちな要素。 NFS 運用方法次第では利用者間で分離設計が必要になる。 バッチの実行もJP1等のスケジューラを使うケースがエンプラ では多く、利用者間での分離設計が必要となる。

生産性と管理性のバランスを取る 利用者の利便性・生産性とエンタープライズとしてのガバナンスを考える どのようにアプリケーションを実装・公開してもらいたいかの「想い」とエンプラとしての担保すべきガバナンスのバランスを設計する ◼ Catalog（ランタイム標準設計） 管理コンソールから好きなランタイムを選んでコードを ビルドしたりアプリ公開したり出来る。 ◼ OperatorHub（クラスタ機能設計） プラットフォームとして必要なクラスタ機能を選択、インストール （有効にする）することができる。 利用者にどのランタイムをどのように使ってもらうか？を設計する。 利用者に提供するプラットフォーム機能を選別する。 やろうと思えば利用するランタイムのパラメータだけでなくコードの ビルド方法、アプリ公開方法まで標準化してここに公開することが できる。（Helm ChartやS2Iを実装・公開） Operatorは沢山のものが公開されているが、無邪気に色々 使わせるわけにもいかない。しっかりと見極めて取捨選択し、 利用者に公開する。

生産性と管理性のバランスを取る 利用者の選択と柔軟性を継続的に維持してくために 作りっぱなしにしていてはすぐに陳腐化して使われなくなるプラットフォームと化す。 プラットフォームとして利用者に何を提供するかを決めるのは難しい ⚫ やりすぎない適切な標準化 利用者を過度に縛る標準は柔軟性を奪い市場競争力を 低下させるが、自由すぎてもガバナンスは効かない。 ⚫ 成熟度的に分相応な機能の選択 OpenShiftの機能や様々なOperatorを色々と使いたく なるが、成熟度的に分不相応なものを選択してもコスト だけかかり全く効果がないこともある。 提供側 利用側 最初に決めたら変えてはいけないものではない。 成熟度を見ながら利用側からFeed Backを受けて継続的 に見直しをかけるという定常運用項目として「運用設計」を すれば良いのではないか？ 技術や文化の成熟度

まとめ 結局現場でやるべきことは昔と変わらないのではないか モノの見え方・価値観の違いでお互いの見ている世界・景色が違うのは程度の差こそあれ今も昔も変わらない。 「なぜ？なんのために？どのように、なにをするか？」 これを表現するのが「設計」であり、モノの見え方をすり合わせ、正しくものを作るための方法ではなかったか。 組織・文化が成熟してから導入する、のがもちろん大事だけど 成熟してきた時のために、先に導入してきちんと価値が出るように設計する そうやって腐らずに地に足をつけて着実にやっていくのが結局近道では？

EOF ご清聴ありがとうございました。 本セッションが多少なりとも日本のエンタープライズの革新に寄与することを願います。