エンプラに Kubernetes を導入してみて分かった 4つの Lessons Learned

エンプラに Kubernetes を
導入してみて分かった
4つの Lessons Learned
September 24th,
OPENSHIFT.RUN 2020,
Daiki Kawanuma

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

エンタープライズにおける Kubernetes 導入あるある
Kubernetes 導入のモチベーション
• リソースの抽象化
Declarative Configuration
• 自己回復性
Self Healing
• 自動スケーリング
Auto Scaling
https://www.datadoghq.com/ja/container-report/
ビジネスのアジリティーを高めること
Kubernetes の本質的な価値
For instance, average container
lifetimes exceed 30 days in 3 percent
of Kubernetes environments.
エンタープライズにおける主要なモチベーション
• コスト削減（インフラの集約性）
• 可搬性、柔軟性のある基盤を選択し将来へ投資
コンテナを避け続けるのがリスクになるのも事実
• 世界レベルで標準化されている
• 時代の流れとして逆らえない
• 巨人の肩に乗る
• “ソリューション要件がコンテナ” ← 間違ってはいない

コンテナ・ Kubernetes に期待を掛ける営業側
Azure AKS
GCP GKE
VMware Tanzu
Kubernetes Grid
on AWS
on Azure
on GCP
on IBM Cloud
IPI & UPI
Kubernetes 戦国時代
• 選択肢として Kubernetes が選ばれやすいのは事実
• 営業としても、お客様にとって価値あるものだと信じている
on Premise

その結果発生する”絵空事の” Kubernetes 導入
べき論はわかってます…
営業の目指した価値を体現するのが現場
たとえアンチパターンでも成功に導かなければいけない使命
絵空事をなんとか、現実の世界に落とし込んでみせよう
※絵空事：絵は実際の物とは違って誇張され美化されて描かれているものであること
Win, Win
Kubernetesは
素晴らしいんやな
Kubernetesは
素晴らしいんです
現場的に厳しい戦いになることは
往々にしてある
『あなたにKubernetesは必要ですか？』
『多分あなたにKubernetesは必要ない』
『Kubernetes の導入時に考えるべきこと』

段階的な Cloud Native 化への道
• ネガティブな表現をしたが、現実問題として一息に Cloud Native 化など不可能
• 許容される変更量、リスク量は限られている
Kubernetes を導入して既成事実を作ってから徐々に文化を変えていくのもまた道
Kubernetes Driven で Cloud Native Journey を歩み出す

自己紹介
Daiki Kawanuma
Associate Architect,
Red Hat Certified Specialist,
AWS Certified Solution Architect
所属
役割レガシーアプリを適切にモダナイゼーションする
働き方
半年から数年程度でお客様を渡り歩く “遊撃隊“ のような働き方
お客様 A社
お客様付きSE
API化案件
お客様 B社
お客様付きSE
新規構築
案件
お客様 C社
お客様付きSE
更改案件
弊部門
時間（半年〜数年で移動）
• 構想策定
• API
• Kubernetes/OpenShift 等
IBM Japan, Cloud Application Services, Modernization Strategy

お客様事例
金融系のお客様
サーバー間取引顧客
ブラウザ顧客
バックエンドシステム
ランクAシステム
法人顧客
従業員
• 約20年の歴史を持つオンプレミスのシステム
• 高可用性／低レイテンシが求められるランクAのミッションクリティカルシステム
• Kubernetes(ICP) で本番稼動中
更
改
サーバー間取引顧客
ブラウザ顧客
バックエンドシステム
ランクAシステム
法人顧客
従業員

お客様事例
 完全にOSと統合、Immutable
 自動化オペレータで高度な自動化
 シームレスにKubernetesをデプロイ
 完全に自動化されたインストール
 ワンクリックでアップデート
 クラウドリソースを自動スケーリング
金融系のお客様
OpenShift＝Enterprise Kubernetes プラットフォームへの移行をご検討中

本セッションのスコープ
Cloud Native 化を進めるアプローチ
Top Down, Bottom UP の両面からのアプローチが不可欠
営業
啓蒙
啓蒙
啓蒙
Bottom UP
Top Down
本セッションのスコープ
開発部門・SIer ビジネス部門・お客様
マネジメント
(意思決定者)
現場
指示
相談
RFP
相談

AGENDA
• Lessons Learned 1：コストとスケール
• Lessons Learned 2：現行運用との兼ね合い
• Lessons Learned 3：モダナイゼーションへの道
• Lessons Learned 4：チーム
• まとめ

Lessons Learned 1：コストとスケール

立ちはだかる税金の高さ
• 4 vCPU
• 16GB Memory
Master Nodes Infra Nodes
× 3ノード
• 2 vCPU
• 16GB Memory
× 3ノード
Worker Nodes
Kubernetes “を”動かすのに必要なリソース＝税金
18 vCPU, 96GB Memory 72vCPU, 110GB Memory
× 40
Pod
※今回の案件においては Datadog 等の SaaS を使う選択肢も無かった
使い方によっては税金が高くみえてしまう（特にインフラの集約性に着目した場合）
今回は税金を払うモチベーションはあまりないので、できるだけ節税したい

• 4 vCPU
• 16GB Memory
Master Nodes Infra Nodes
× 3ノード
• 2 vCPU
• 16GB Memory
× 3ノード
Worker Nodes
× 40
Pod
削れない槍玉に挙がるのはここ
トラディショナルな方法でもできるんじゃないの？
直近は要らないんじゃない？
今後 Kubernetes をやっていくなら必須なのだが…
だが、今を乗り切る方法もあると言えばある

実際に、Kubernetes では泣く泣く削りました
Master Nodes Infra Nodes Worker Nodes
Promtail
開発環境
ステージング／
本番環境
Shell
kubectl get pod
kubectl top podLocal PV
軽量な PLG を
選択
Grafana は非常に便利だった。
何かが起こったとき（障害・負荷試験等）に状態の推移をグラフィカルに見られるのは良い
また、ログを各ホストサーバーへ取得しにいくのはやはり面倒だった。

OpenShift では Infra Node の導入を検討中
Master Nodes Infra Nodes Worker Nodes
開発環境
ステージング／
本番環境
• Red Hat のサポートが付く EFK を選択
(ただし運用のコアとはしない後述)
• Prometheus/Grafana はコアコンポーネントとして実質必須

Lessons Learned
• Master や Infra の税金に勝るある程度の規模の Worker ノードにしたい（マルチテナントも有効）
• とは言え、最初からでかいクラスターから始めるのは難しい場合が多い
• 将来像と合わせて投資ということにする
• TCO で比較する
• 現行のコストと比較する
• 当たり前だが、ロギングやモニタリングのコンポーネントを入れないと後で辛くなる
• システムとしての重要性に加え、ビジネス面でも価値を訴求したい
デイリーアクティブユーザー都道府県別アクセス数成約率 OS /ブラウザ別アクセス数

最近の個人的疑問
EFK が特に重い
EFK vs. PLG
https://www.cncf.io/blog/2020/07/27/logging-in-kubernetes-efk-vs-plg-
stack/
将来的に OpenShift に PLG の採用はあるのか？

スケーラビリティに制限のあるオンプレ環境
基本的にHWを自由に増減させることはできなかった
• ギリギリのリソースでやりくりする場合が多くなる
• Requests を調整して押し込めるしかない Infra Node #1 Requests CPU: 98%（定常時は30%程のCPU使用率）
• Alertmanager は監視のコアコンポーネントとして用いる
• 運用上クリティカルになるものは減らせない
コアコンポーネントも減らせない
サービスレベルで Requests を決める
• サービスレベルは気にしない
(運用のコアコンポーネントにはしない)
• まずは導入したい（入れることに意義）

リソースの調達には時間が掛かる
• リソース追加には決済が伴うので、おいそれとリソース追加はできない
• リソース見積もりをある程度精緻に行う必要がある
• Core / Memory は Hardware Requirements として記載あり
• OpenShift の場合 CR にデフォルト値として設定されている
• ストレージ容量見積もりの手法
• アプリケーションログは現行をベースにサイジング
• Elasticsearch は INDEX を張る関係上、ログ容量の3~5倍で見積もり
• コアコンポーネントのログ／メトリクス量は検証クラスターで確認
検証クラスター（UPI）＠
問題はストレージ容量の見積もり

Lessons Learned
• 大前提として、余裕のあるリソース確保には尽力したい
• そうは言っても確保が難しい場合もあるかもしれない
• サービスレベルを決める
• Requests / Limits を駆使する
• スケーラビリティに制限があるなら、尚更 PoC の重要性は高まる
• リソース見積もりは実際に動かしてみることが一番
• PoC をして Feasibility を見極める（リソース見積もりに限らず重要）

Lessons Learned 2：現行運用との兼ね合い

現行運用ソフトウェアとのインテグレーション
現行運用
SW(master)
• プロセス監視
• メトリクス監視
• ログ監視
現行の運用方式
システムA
現行運用
SW(agent)
現行運用
SW(agent)
現行運用
SW(agent)
システムB
・・・
システムN
Kubernetesだけ
別のシステム監視とはいかないな
※許容されるリスク量・変更量の話も関係する
現行運用
SW(agent)
現行運用
SW(agent)
• 統合監視基盤で運用を行っている

ソリューション（プロセス監視・メトリクス監視）
Alertmanager
Endpoint
現行運用
SW(agent)
現行運用
SW(master)
運管サーバー
アプリケーション Pod, コアコンポーネント Pod
カスタム Pod
Master, Infra, Worker Nodes

ソリューション（ログ監視）
現行運用
SW(agent)
現行運用
SW(agent)
現行運用
SW(agent)
現行運用
SW(agent)
現行運用
SW(agent)
現行運用
SW(agent)
現行運用
SW(master)
アプリケーション Pod
Red Hat
Enterprise Linux
Worker Nodes
• Worker Node には RHEL を採用

運用文化とのせめぎ合い（インターネット接続）
オンプレ環境はインターネット接続不可
お客様DC
• オンプレ環境は基本的にインターネット接続不可
• 対象システムでインターネット接続を行った実績はなし
OpenShift 4 のインストール方法
1. 直接接続方式
2. プロキシー接続方式
3. オフライン方式
ヤバイ、辛いという
前評判を聞いた
https://rheb.hatenablog.com/entry/openshift42-proxy-upi
絶対に通さないと辛い
通さないといけない前提で話をもっていく

プロキシー接続方式
registry.redhat.io
*.quay.io
sso.redhat.com
cloud.redhat.com
mirror.openshift.com
*.cloudfront.net
quay-registry.s3.amazonaws.com
api.openshift.com
art-rhcos-ci.s3.amazonaws.com
nginx.org
OpenShift 4 のファイアウォール設定
• 当然 FQDN です。ありがとうございます。
• FQDN指定が可能なFWを選択する必要があった

実際の穴あけドタバタ劇
僕お客様セキュリティ統括
FW申請書
• 月末締め
• 翌月末穴あけ実施
統合FW 担当者
穴あけ
『穴あけまでに実質2ヶ月程度掛かる』
registry.redhat.io
*.quay.io
sso.redhat.com
cert-api.access.redhat.com
api.access.redhat.com
infogw.api.openshift.com
https://cloud.redhat.com/api/ingress
storage.googleapis.com/openshift-release
*.apps.<cluster_name>.<base_domain>
api.openshift.com
api.openshift.com
cloud.redhat.com/openshift
FW申請書
いざ、インストール！
ERROR xxx xxxxxx
ERROR xxx xxxxxx
ERROR xxx xxxxxx
ERROR xxx xxxxxx
ERROR xxx xxxxxx
失敗！！！

実際の穴あけドタバタ劇
registry.redhat.io
*.quay.io quay.io
sso.redhat.com
2ヶ月のロスタイム
今度は失敗するわけにはいかない…
お家 N/W
MacBook Pro
Proxy
サーバ
OCP
master #1-
3
OCP master
#1-3
OCP infra
#1-2
OCP infra
#1-2
OCP
worker #1-
3
OCP worker
#1-3
Red Hat
Servers
Broadband
Router
Firewall
以下の通信以外は拒否する様に設定
• DNS
• HTTP
• HTTPS
拒否された通信をログに出力し、下記の各
OCPサーバーから Proxy を経由しない通信 (≠
HTTP(s) の通信) の有無を洗い出す
HTTP(S)の
ログを取る
自分の MacBook Pro で検証

registry.redhat.io
*.quay.io
sso.redhat.com
cloud.redhat.com
*.cloudfront.net
api.openshift.com
nginx.org
quay.io
infogw.api.openshift.com
cdn.redhat.com
storage.googleapis.com
subscription.rhsm.redhat.com
結果の申請書
• 開発・構築時の留意事項
• 現行のネットワーク文化がある場合は要注意
• リードタイムを短くする努力をするか、2,3回失敗しても大丈夫なスケジュール的余裕を持つべき
• 今後の保守に向けて
• マイナーバージョンアップグレードで接続先が増減することは容易に想像できる
• アップグレード失敗時の対策として最低限、FWのログ取得は必須
• 合わせて、よりスピーディーなワークフローへの改善にも努力したい
Lessons Learned

Lessons Learned 3：モダナイゼーションへの道

Lessons Learned ３：モダナイゼーションへの道
アプリモダナイゼーション
The Twelve-Factor App を指針の1つとする
概要説明方針
1. コードベースバージョン管理されている1つのコードベースと複数のデプロイ対応済
更改前からSubversionを利用
複雑化したアプリケーションを整理する余地はまだまだ存在する
2. 依存関係依存関係を明示的に宣言し分離する対応済
更改前からMavenを利用
DockerfileによりOSレベルの依存関係まで明示的になった
3. 設定設定を環境変数に格納する対応環境設定用XMLファイルから環境変数に置換
4. バックエンドサービスバックエンドサービスをアタッチされたリソースとして扱う対応なし
バックエンドが変更できないため
特にGWと呼ばれるキューイングサービスとは密結合している（独自実装を多く含む）
5. ビルド、リリース、実行ビルド、リリース、実行の3つのステージを厳密に分離する対応済コンテナの可搬性により、ステージの分離がより厳密になった
6. プロセスアプリケーションを1つもしくは複数のステートレスなプロセスとして実行する対応なし
アプリケーション改修のコストが非常に大きいため
バックエンドが変更できないため
7. ポートバインディングポートバインディングを通してサービスを公開する対応
アプリケーションサーバーを含むコンテナイメージとKubernetesのServiceの機能によってプ
ロセス間の通信を制御する
8. 並行性プロセスモデルによってスケールアウトする対応（一部）
アプリケーションを細かいプロセスに分離する、ただしマイクロサービス化はしない
一部アプリケーションのみ Deployment によるスケールアウトが可能になった
9. 廃棄容易性高速な起動とグレースフルシャットダウンで堅牢性を最大化する対応（一部）
コンテナ化によってプロセスの軽量化を実施（主にミドルウェア）
アプリ的なグレースフルシャットダウンには非対応
10. 開発/本番一致開発、ステージング、本番環境をできるだけ一致させた状態を保つ対応（一部）
時間のギャップ：本番環境への適用に要する時間が2時間から1時間に減少
人材のギャップ：一部あり
ツールのギャップ：コンテナにより開発環境でも容易になったが、GWに課題あり
11. ログログをイベントストリームとして扱う対応なしロギングコンポーネントの不採用およびロギング機能の変更負荷により断念
12. 管理プロセス管理タスクを1回限りのプロセスとして実行する対応（一部）
管理スクリプトの一部はコンテナイメージ内に同梱されコンテナ内で実行されるが、
手動実行の運用手順も残っている

Git 移行と Single Source of Truth
Subversion から Git へ
• 約20年間 Subversion で運用されてきた環境を段階的に Git へ移行
• コンテナ／Kubernetes 周りから Git 化を始める
• 様々なツールが Git を前提に作られている
• GitOps をしたい！
• スキルフルな要員が集まりやすいので Git 移行の障壁が小さい
Single Source of Truth
• 動かすために何をすればいいか分からない
• ドキュメントもどこにあるか分からない
• コンテナや Kubernetes により IasC, CasC が非常にやりやすくなった
• YAML や Dockerfile が設計書そのもの
• あとはその設計に至るまでの AD(Architecture Decision) がわかれば良い
Excel 設計書＋ Redmine Wiki
Subversion で管理されている
ソースコード全体
今回 Git 移行のスコープとした
コンテナ・Kubernetes 周りは全体の 2.4%
まだまだ先は長いが、何事も小さな一歩から
脱却したい
ソースコード＋ Markdown

本当に必要な CI/CD
• Kubernetes の早いライフサイクルに対応する必要がある
(3ヶ月ごとのマイナーバージョンリリース、半年ごとのアップグレードの必要性)
• 今までのN年塩漬けとは全く異なる考え方が必要になる
• 本当に必要な CI/CD ってなんだっけ？
• テストを自動化しましたが CI/CD じゃないないよね？
• 目的とゴールを再確認しよう
【目的】
• 何らかの変更があってもサービスに影響が無いことを確認する
【ゴール】
• リリース・クライテリアを決める
• それをできるだけ素早く簡易に実行できるようにする
(自動化が絶対の手段とは限らない)
何らかの
変更
リリース・クライテリア
・ xxx
・ xxx
・ xxx
何かしらの自動化
簡易な手動実行
リリース
https://access.redhat.com/ja/support/policy/updates/openshi
ft
OpenShift のライフサイクル

• どのレイヤーまでをスコープとするか
Host OS
Orchestration
Container Container Container Container
Container Runtime
Automated Operations
Manifest Manifest
Package Manager
Cluster / Application/ Developer Services
マニフェスト〜アプリケーションの機能確認は当然やるでしょう
各種 Operator や Prometheus 等の Cluster Service はどうしよう
性能や可用性等の非機能確認はどうしよう
非機能どこまでやろう？
インフラの CI やる？
• どこまで自動化／パイプライン化するか
ソースコード取得ビルド単体テストパッケージコンテナビルド結合テストアーティファクト登録ステージングデプロイパフォーマンステスト等

Git 移行と Single Source of Truth
Lessons Learned
• 技術よりは仕組みやプロセスといったメタなことが障壁になりやすい
• 活発に議論できるメンバーを3人以上集めたい
• 現行の仕組みに詳しい人を巻き込むことも重要
• まずは「やってみる、やって見せる」ということが重要に感じる
• 内容が良ければ、「一緒にやりたい」と言ってくれる人が現れる
• Tool Driven でも大いに結構
• 導入してみると案外上手く動き出すってこともある
メタな議論にも直地点を付ける（自戒）

Lessons Learned ４：チーム
Kubernetes に適応したチームつくり
OpenShift のサポート期間
• マイナーバージョンのサポート期間は約9カ月
• アップグレード期間も考慮すると半年ごとのアップグレード作業が必要
スーパーマンが一人は居ないと厳しい
(本当は複数人ほしい)
• 作りきったら終わりではない（≠塩漬
け）
• 継続的な保守が不可欠
https://access.redhat.com/ja/support/policy/updates/openshi
ft

お客様付きSEへのスキトラ
お客様付きSE
• 基本的なコマンド操作は習得済み（ kubectl get pod 等）
• Kubernetes の仕組みはまだ理解不十分
僕
• 障害解析ができる
• リリースノートが読める
• 人に教えられる
お客様付きSE
お客様付きSEのみで Kubernetes の保守を回せることが理想

OpenShift スキル獲得
https://www.redhat.com/ja/services/training/do288-red-hat-
openshift-development-i-containerizing-applications
1. Red Hat OpenShift Development I: Containerizing Applications 2. 週1回程度のスキトラ
SA Role
Role
Binding

OpenShift スキル獲得
3. Operator ハンズオン
https://github.com/Daiki-Kawanuma/kubernetes-operator-handson
• OpenShift の設定は基本的に CR の適用で行われる
• Operator の概念の理解が不可欠
『最小構成』の
なんちゃって Operator
4. 社内勉強会の企画
• 最終的には Kubernetes を『教える側』になってほしいという期待
• 人に教えるには3倍の理解が必要
若手（1〜3年目）への勉強会を企画中

Lessons Learned
2. いきなり全部を教えすぎない
いきなり全部並べられても分かるわけがない
相手の知識レベルに合わせて“教え過ぎない”ことを意識する
勉強したい人が自分のレベルが分からない・その人のレベルにあったコンテンツが無いのが辛い
そもそもDockerの良い点や動かし方がわかっていない時にいきなりK8sの概念を聞いてもよくわからな
い
コンテナに限らずそれぞれの人のレベルに合わせた説明やコンテンツは需要があるのかなと思う
1. ユースケースで刺す
概念や機能を教えても腹落ちしづらい（Kubernetes のジャズ的な性質）
ユースケースに刺して機能を教えていく
一緒にハンズオンやりながら説明していただけたのはめちゃくちゃ良い
あとは実際に動かせる環境が準備されているというのも良い
3. 自分の作業過程や情報源をオープンにする
考え方や思考過程を目に見えるところに置いておく
気づいてもらう工夫をする
何を知っているべきか、何ができればいいのかがわからない
欲しいのは結果を導くための途中経過
4. 手を動かさせる、自分でやらせる
手を動かさないと始まらない
運用引き継ぎフェーズで一挙にスキトラは絶対に機能しないのでやめた方が良い

• 本番稼動中だが、今のところコンテナ起因の障害は０
• お客様のモチベーションであったインフラコストは集約は達成できた
• 既存運用方式とのインテグレーションも問題なく実施できた
• Lift & Shift の “Lift” を成功裏に実施できた
まとめ
で、実際に Kubernetes 導入どうだったの？
サービス目線
• リリース作業に要する時間が2時間から1時間に短縮できた
• Kubernetes のリソースの集約化／抽象化という側面も開発の効率化に寄与した
開発目線
あるべき姿を定義しておけばあとはk8sが色々やってくれるというのは便利ですよね
あとリソースの種類とかがわかっていればどこに定義が書いてあるかとかも探しやすいのがいいなと思います
エンプラど真ん中のシステムに Kubernetes を導入したが、ちゃんと運用できてる

• ビジネスアジリティを求めるのか
• 運用の自動化を求めるのか
• 開発生産性の向上を求めるのか…etc
まとめ
コンテナ化第二章に向けて
今後、どんな Shift を描くか、Kubernetes に何を求めるのか
• ビジネスアジリティの話をすると、今回削減できたのは全体のごく一部でしかない
• 本当に効果を上げようと思ったら、改善できる箇所がまだまだ沢山ある
やはり組織・文化と向き合うことは避けられない
リリースまでに要する時間
今回の Kubernetes 導入で
削減できた時間
• チーム全体のスキルアップが必須だが、まずは一人目のスーパーマンの育成が急務
• とは言え、一人のスーパーマンに頼っていてはスケールしないので、スケールする仕組み作りが組織として必要
これから本格的に始まる Day2 Operation, Kubernetes を保守する辛みと向き合う

まとめ
コンテナ化第二章に向けて
Kubernetes を活かすも殺すも今後次第
お客様と共に、全方位でやっていき

EOF
Special Thanks
• Satoshi Doi
• Yusuke Urakawa
• Hiromitsu Iwata
• Kensuke Shigyo
ご清聴ありがとうございました。

エンプラに Kubernetes を導入してみて分かった 4つの Lessons Learned

Recommended

More Related Content

What's hot (20)

Similar to エンプラに Kubernetes を導入してみて分かった 4つの Lessons Learned (20)