エンプラもOpenshiftでプラットフォームを作りたい

エンタープライズでOpenShiftを導入するだけでも大変な辛みがありますが、様々なしがらみを乗り越えて構築できたとしてもそれで終わりではありません。大部分はコストの観点で、アプリケーション毎にOpenShiftを構築する、ということはエンタープライズではナンセンスで『共通基盤』としてプラットフォーム構築構想を立てるのが一般的でしょう。本セッションではエンタープライズが夢見るプラットフォーム構想を実現する為に、現場とステークホルダー間で起こりがちな認識のズレはなんなのか、どのようなことに気をつけてで進めていけば良いのかをご紹介します。

Transcript

1. エンプラもOpenShiftでプラットフォームを作りたい ~「OpenShiftという『ミドルウェア』が⼊ったサーバ」にしないために~ 2020-12-10 OPENSHIFT.RUN Satoshi Doi IBM Japan, Ltd.
2. 本セッションは個⼈の⾒解であり、 所属組織の⽴場、戦略、意⾒を代表するものではありません。 また、技術的な内容にも⾔及しますが、正確性を保証するものではありません。 免責事項
3. ⾃⼰紹介 Satoshi Doi @satoshi55d Application Architect Red Hat Certified Specialist IBM Japan, Cloud Application Services, Modernization Strategy 転職組 2019年2⽉からIBM 私 (怖くない⽅のIBM) 怖いIBMさん達 ❤ OpenShift IBM製品で唯⼀好きなのがLiberty 最近意外とできる⼦なんだと気がついた
4. エンプラの選択するOpenShift利⽤形態 コストの観点でまずはマルチテナントな形態を選択する場合が多い 利⽤ユーザ・アプリ 利⽤ユーザ・アプリ n マルチテナント コスト効率: ◎ アプリ独⽴性: △︖ n マルチクラスタ コスト効率: × アプリ独⽴性: ◎ 本セッションは こちらを前提にお話します。
5. エンプラあるあるプラットフォーム構想 システム更改の「ついで」にふわっとプラットフォーム化を志す n 作りたいもの OpenShiftで様々なアプリ、サービスが稼働 更改後システムはそのうちの「⼀つ」 なんかDXとか推進出来るなにか n 出来上がるもの 更改後システム「⽤」のOpenShift 計画的ならまだしもこれでペイするのか︖ プラットフォーム︖ 更改後システム OpenShiftという『ミドルウェア』が⼊ったサーバ群 現実は‥
6. ＿＿＿＿＿＿＿＿＿＿＿＿ ヾミ || || || || || || || ,l,,l,,l 川〃⼺| V~~‘’-⼭┴‘’‘’“”~ ヾニﾆ⼺| 作る・・・・・・︕ / ⼆ー―‘’⼆ ヾﾆニ┤ 作るが・・・ <'-., ￣￣ _,,,..--､ 〉ニﾆ| 今回 まだ その時と場所の /"''-ﾆ,-l l`__ニ--'''""` /ニ⼆| 指定まではしていない | ==＝､! `＝====､l =ｌべ=| . | `ーﾟ-'/ `ー-ﾟ―' l.=lへ|~| そのことを |`ー-/ `ー―― H<,〉|=| どうかエンプラのお客様も | / ､ l|__ノｰ| 思い出していただきたい . | ／`ー ~ ′ ＼ .|ヾ.ニ|ヽ |ｌ 下王l王l王l王lヲ｜ | ヾ_,| ＼ つまり・・・・ . | ≡ | `l ＼__ 我々がその気になれば !、 _,,..-‘′ ／l | ~’‘’ プラットフォームの完成は -''"￣| `iｰ-..,,,＿,,,,,....--'''" ／ | | 10年後 20年後ということも -―| |＼ ／ | | 可能だろう・・・・・・・・・・ということ・・・・︕ | | ＼ ／ | | エンプラあるあるプラットフォーム構想 ⽬指す姿の『共通認識』ができないままではいつまで経っても完成しない
7. 誰も狙って無価値な基盤を作ろうなどと思っていない なぜこのようなことが起きるのでしょうか︖ 「だから散々⾔ったのに…」 現場では問題を指摘したのに受け⼊れてもらえなかった︖ ステークホルダー達のK8sの理解が不⼗分︖ 彼らがK8sを理解しようともしないで現場任せにしているから悪い︖ いいえ︕ 「K8sがこれまでのトラディショナルなテクノロジーの考え⽅とかけ離れて おり、⾒るべき世界・景⾊が違っていることに気づかないから」 と考えた⽅が建設的ではないでしょうか︖ 本セッションでは、 ① ステークホルダーとの認識齟齬を把握し、 ② そんな彼らとどのようにプラットフォームを作っていけば良いのか をK8s/OpenShiftの機能も絡めつつご紹介します。 本⽇お話ししたいこと お互いの⾒る世界・景⾊を⼀致させて 『共創』するために
8. ステークホルダーとの認識の違いを把握する
9. ステークホルダーの定義 それぞれの⽴場、それぞれのフェーズでステークホルダーは様々 本セッションでのステークホルダーとは n 社内: プロジェクトマネージャ、チームリーダ、 他チーム（基盤チーム、アプリチーム） 営業、コンサル n 顧客: 担当者、エグゼクティブ といった、K8s / OpenShift導⼊に関わる重要な意思決定や設計を⾏うキーマンを指します。 各⾃のステークホルダーを思い浮かべながらお聞きください。
10. 我々が思うKubernetes/OpenShift 「プラットフォームを作るためのプラットフォーム」 これ単体で何ができるわけではなく、プラットフォームの志向性が⼤事
11. ⼤部分のステークホルダーが思うKubernetes/OpenShift ! " # $ % & 違 ( ) * + , - . / 0 1 2 3 ！ 違 2 & 0 ‼ これまでは に をデプロイしてた Applicationサーバ WAR これからは に をデプロイする︕ OpenShift コンテナ
12. OpenShiftはミドルウェアじゃないと思うの… 確かにOpenShiftってやつは 『機能』が豊富だし⾊々と 出来るらしい。 ⾼機能なミドルウェアってことかな。 『ミドルウェア』として捉えて単純に機能だけを⾒てしまう これらを使って何を成すか、が⼤事なんですけど…
13. 「基盤」コストに⽬がいくのもわかるけど… LB Web + Application Server DB Server アプリ利⽤者 ああ、なるほど。 いつもの構成をOpenShiftに集約 できるんだね。 基盤コスト圧縮できてこれは良いね。 「基盤」の集約という⼀⾒わかりやすそうなメリットだけを⾒てしまう いつもの構成 （よくあるWeb・AP・DBの3層構成） そこをメインの価値にするともったいないのでは… そもそもTCOで⾒てちゃんとペイ出来るか⾒積もった︖
14. ⾒てる世界の違いで発⽣する誤ったスコープ・ゴール設定 OpenShiftによってプラットフォーム を構築し、その上で複数のアプリケー ションを迅速に展開出来るようにして いきましょう︕ うんうん、そうだね。 でも予算も限られているわけだから先ずは 更改するシステムをターゲットして作って、 そこから『段階的に』⼤きくしていこう。 共通基盤構想はその後で考える でも良いじゃないか。 共通基盤 (⾃⽴分散 < 中央集権) プラットフォーム （⾃⽴分散 > 中央集権）
15. ⻑年培ってきた考えを覆すのは⾄難の技 中央集権的な「共通基盤」をしっかりと「管理」してきた歴史 n エンタープライズは歴史的に、SOA基盤のような中央集権的システム管理を⾏ってきた Ø トップダウンで統制をとることで⼤規模なシステムを安全に効率良く管理する仕組みとして機能した プラットフォーム︖ 更改後システム 新規アプリ ⻑年彼らが実践し、成功体験を重ねてきた考えに基づいている しっかりと管理すればなんであれ使うことができる（と思っている） だからアプリからインフラまでしっかりと中央集権的に管理したがる その結果出来上がるOpenShiftというミドルウェアの⼊ったサーバ群 既存の共通基盤より⼿のかかる中央集権管理OpenShift
16. これだからエンプラは…。そう思って諦めてませんか︖ DXへ導くビジネスプラン あるべき組織・⽂化の醸成 K8sの真の価値とは︖ ︖︖︖︖ トップダウン ボトムアップ 『あなたにKubernetesは必要ですか︖』 『多分あなたにKubernetesは必要ない』 『Kubernetes の導⼊時に考えるべきこと』 確かに、彼らのマインドセットを変えるの は⼀朝⼀⼣では難しい。 しかしながらそれを認めた上で、現場で できることはないのか︖ 彼らのマインドセットが醸成された未来を ⾒据えて無駄にならないプラットフォーム を作ることはできないのか︖ ぐうの⾳も出ないほど正しい。 それ相応のビジネスプランがあり、そのためのあるべき 組織や⽂化を醸成、それでこそK8s/OpenShiftの 真価が発揮できる。 現場じゃどうしようもないよ…。 ボトムアップでできることだってあるはず
17. ステークホルダーと何をもってすり合わせていくべきか︖
18. まずちゃんと『設計』しませんか︖ 「設計」としてアウトプットするものも変えていかなければならない 現場としても既存の設計「しか」しておらず、K8sというプロダクトの暗黙の定義に頼っているところがあるのではないか︖ 「設計」としてステークホルダに説明するなら彼らの⼟壌で等しく会話ができるはずではないか︖ そして、例え彼らに「今は」理解されなくても、理解された時に作り直ししなくても良いように「準備」できるのではないか︖ n これまでやってきた設計内容 ・アプリ設計 ・インフラ設計 ・ミドルウェア設計 ・⾮機能設計 ・運⽤設計 ・環境定義書 etc. 設計書の名前やフォーマットはなんでも良いが、その中で 以下のような設計項⽬をプラットフォーム設計としてきちんと含めているか︖ 1. プラットフォームとして⽬指す姿を定義する 2. 責任境界を明確にする 3. 共有と分離設計を⾏う 4. ⽣産性と管理性のバランスを取る そういった観点で、設計項⽬という名のボトムアップでステークホルダーとすり合わせていくべき項⽬をいくつかご紹介します。
19. Master * 3 OS: RHCOS CPU: 8 core Memory: 64 GB Infra * 3 OS: RHCOS CPU: 4 core Memory: 64 GB Worker * 3 OS: RHCOS CPU: 8 core Memory: 64 GB Internal LB External LB プラットフォームとして⽬指す姿を定義する n 「基盤」としてのVIEW n 「プラットフォーム」としてのVIEW 必ず作る、とても⼤事な設計資料だけど、これだけでは⾜りないのでは︖ Ø 基盤をどのように利⽤者に使ってもらうか︖の定義がされていない。 運⽤・監視設計 可⽤性設計 バックアップリカバリ etc. サーバ構成 ネットワーク構成 ストレージ構成 ミドルウェア構成 プラットフォームとして⽬指す姿やコンセプトを定義する。 Ø 如何に「管理する」か、ではなく如何に「運営する」か。 システムA App App App App インフラリソース (CPU、メモリ、ネットワーク、ストレージ、etc.) サービス機能・共有知 (アプリランタイム、標準設計) システムB App App App App システムX App App App App システムY App App App App 利⽤側 提供側 利⽤ & Feed Back 提供 提供 利⽤者 クラスタ管理者・インフラ管理者 機能整備・標準化担当者 連携 表裏⼀体
20. 責任境界を明確にする 責任境界を適切に定義しなければ中央集権管理される巨⼤なモノリシックシステムになる 「曖昧な責任境界」、「利⽤者に許容する少なすぎる裁量」が不要な組織間コミュニケーションを増⼤させモノリシックを作る。 何でもかんでも「管理者」という曖昧なロールが⾏う前提 Ø こうなってしまうと何を頑張ってもモノリシックまっしぐら どのロールに、何を、どこまで許容するか明確にする Ø プラットフォームの⽬指す姿に合わせてきちんと設計する (もちろん技術的にどこまで権限分離できるか知ることも重要) 利⽤側 提供側 n 避けたいロール設計（設計しないと⼤体こうなる） n 最低限考えておきたいロール設計 利⽤者がどこまで⾃由にできるか︖をまず決める。 利⽤者内でのロール設計は利⽤者に移譲。 インフラ、クラスタ管理者、標準化担当など、 組織や運⽤体制を踏まえて決定する。
21. 共有と分離設計を⾏う マルチテナント設計は必須。最初から意識して設計する プラットフォームの共有には必要な機能を使って適切に分離しないと実質不可能 直近プラットフォームに載せるアプリが⼀つだとしてもやっておかないと後から別なアプリが載る時の影響が⼤きくなる l Quota インフラリソースの適切な割り当て。リソース不⾜の影響を分離。 Namespace A Quota Limit Range Limit Range Namespace B Quota Limit Range Limit Range l 変更プロセスはとても⼤事だけど成熟度に合わせて柔軟に Network Policy, Quotaの利⽤者からの変更依頼発⽣時の変更 プロセスは導⼊先の組織・⽂化の成熟度に合わせて柔軟に。 ただし、変更に数週間、数ヶ⽉かかります、みたいな変更プロセスに なると全てが台無しなので上記のデフォルト設定も含めてしっかりと すり合わせる。 （頑張りどころだけど、流⽯にこの辺は組織や⽂化からは逃げられないか…） l Network Policy 適切なネットワークセキュリティ設計による分離。 DB A DB B Deny Deny allow allow allow allow Network Policy Namespace A Namespace B Network Policy Open Policy Agent Project Template l Namespaceのデフォルト設定 左の分離設定は都度設定していては管理者の負荷が⾼まるし 初期設定ガバガバはまずい。デフォルト値⼤事。 OpenShiftだとNamespace作成時に作られるデフォルトリソースを設定しておける Open Policy Agentをこの辺の管理に使っても良いかもしれない
22. OpenShiftで考えてくれているマルチテナント機能 OpenShiftでは最初からマルチテナントを志向して⽤意してくれている機能があるので必要に応じて使う。 特にありがたいのが、「ログ基盤」と「監視基盤」 共有と分離設計を⾏う l ログ基盤 Elasticsearch & SearchGuard マルチテナントなEFKスタックが⽤意されている。 Elasticsearch Namespace A ログデータ Namespace B ログデータ allow allow deny Namespace A 利⽤者 Namespace B 利⽤者 Namespace毎にログ保有期間も調整できるので適宜設計する。 クラスタ管理者しか⾒れないけど利⽤者もみたいログがあるか︖なども検討。 l 監視基盤 User Workload Monitoring 利⽤者が使うPrometheus管理Operatorが4.6で遂にGA︕ それぞれのCustomResourceをapplyすることでPrometheusに設定してくれる。 • Service/PodMonitor Prometheus Targetの設定 • PrometheusRule Prometheus Ruleの設定 CustomResorceを経由して⼀つのPrometheusを共有する仕組み。 （Alertmanagerは適宜全体設計しないとダメか。） User Workload Monitoring Namespace A Prometheus Rule Service/Pod Monitor Namespace B Prometheus Rule Service/Pod Monitor Watch
23. OpenShiftはプラットフォームを構成する⼀つの要素にすぎない 「OpenShift」のマルチテナント設計に注⼒しがちだが、OpenShiftを取り巻く周辺要素も忘れてはならない。 共有と分離設計を⾏う Gitlab Container Registry 資産管理 NFS DB 永続化 バッチ管理 運⽤管理 運⽤ LB ネットワーク OpenShiftクラスタ l 資産管理 マルチテナントなプロダクトの選定と管理体系の設計 l ネットワーク 特定アプリにターゲットしてLBの性能やネットワーク帯域を⾒ 積もると死ぬ。意外とこの辺ボトルネックになりやすい。 l 永続化 クラスタの外にDB置くなら共有か独⽴かの選択。 PVは⼤体NFSなのでここも共有か独⽴かの選択。 l 運⽤ 結構マルチテナント設計で⾒逃しがちな要素。 運⽤⽅法次第では利⽤者間で分離設計が必要になる。 バッチの実⾏もJP1等のスケジューラを使うケースがエンプラ では多く、利⽤者間での分離設計が必要となる。
24. ⽣産性と管理性のバランスを取る 利⽤者の利便性・⽣産性とエンタープライズとしてのガバナンスを考える どのようにアプリケーションを実装・公開してもらいたいかの「想い」とエンプラとしての担保すべきガバナンスのバランスを設計する n Catalog（ランタイム標準設計） 管理コンソールから好きなランタイムを選んでコードを ビルドしたりアプリ公開したり出来る。 n OperatorHub（クラスタ機能設計） プラットフォームとして必要なクラスタ機能を選択、インストール （有効にする）することができる。 利⽤者にどのランタイムをどのように使ってもらうか︖を設計する。 やろうと思えば利⽤するランタイムのパラメータだけでなくコードの ビルド⽅法、アプリ公開⽅法まで標準化してここに公開することが できる。（Helm ChartやS2Iを実装・公開） 利⽤者に提供するプラットフォーム機能を選別する。 Operatorは沢⼭のものが公開されているが、無邪気に⾊々 使わせるわけにもいかない。しっかりと⾒極めて取捨選択し、 利⽤者に公開する。
25. 利⽤者の選択と柔軟性を継続的に維持してくために 作りっぱなしにしていてはすぐに陳腐化して使われなくなるプラットフォームと化す。 利⽤側 提供側 技術や⽂化の成熟度 プラットフォームとして利⽤者に何を提供するかを決めるのは難しい l やりすぎない適切な標準化 利⽤者を過度に縛る標準は柔軟性を奪い市場競争⼒を 低下させるが、⾃由すぎてもガバナンスは効かない。 l 成熟度的に分相応な機能の選択 OpenShiftの機能や様々なOperatorを⾊々と使いたく なるが、成熟度的に分不相応なものを選択してもコスト だけかかり全く効果がないこともある。 最初に決めたら変えてはいけないものではない。 成熟度を⾒ながら利⽤側からFeed Backを受けて継続的 に⾒直しをかけるという定常運⽤項⽬として「運⽤設計」を すれば良いのではないか︖ ⽣産性と管理性のバランスを取る
26. まとめ 結局現場でやるべきことは昔と変わらないのではないか モノの⾒え⽅・価値観の違いでお互いの⾒ている世界・景⾊が違うのは程度の差こそあれ今も昔も変わらない。 「なぜ︖なんのために︖どのように、なにをするか︖」 これを表現するのが「設計」であり、モノの⾒え⽅をすり合わせ、正しくものを作るための⽅法ではなかったか。 組織・⽂化が成熟してから導⼊する、のがもちろん⼤事だけど 成熟してきた時のために、先に導⼊してきちんと価値が出るように設計する そうやって腐らずに地に⾜をつけて着実にやっていくのが結局近道では︖
27. EOF ご清聴ありがとうございました。 本セッションが多少なりとも⽇本のエンタープライズの⾰新に寄与することを願います。