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

OPENSHIFT.RUN Summer 2020 登壇スライド

Transcript

1. エンプラに Kubernetes を 導⼊してみて分かった 4つの Lessons Learned September 24th, OPENSHIFT.RUN 2020, Daiki Kawanuma
2. 本セッションは個⼈の⾒解であり、 所属組織の⽴場、戦略、意⾒を代表するものではありません。 また、技術的な内容にも⾔及しますが、正確性を保証するものではありません。 免責事項
3. エンタープライズにおける 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. エンタープライズにおける主要なモチベーション • コスト削減（インフラの集約性） • 可搬性、柔軟性のある基盤を選択し将来へ投資 コンテナを避け続けるのがリスクになるのも事実 • 世界レベルで標準化されている • 時代の流れとして逆らえない • 巨⼈の肩に乗る • “ソリューション要件がコンテナ” ← 間違ってはいない
4. エンタープライズにおける Kubernetes 導⼊あるある コンテナ・ Kubernetes に期待を掛ける営業側 Azure AKS GCP GKE VMware Tanzu Kubernetes Grid on AWS on Azure on GCP on IBM Cloud IPI & UPI Kubernetes 戦国時代 • 選択肢として Kubernetes が選ばれやすいのは事実 • 営業としても、お客様にとって価値あるものだと信じている on Premise
5. エンタープライズにおける Kubernetes 導⼊あるある その結果発⽣する”絵空事の” Kubernetes 導⼊ べき論はわかってます… 営業の⽬指した価値を体現するのが現場 たとえアンチパターンでも成功に導かなければいけない使命 絵空事をなんとか、現実の世界に落とし込んでみせよう ※絵空事︓絵は実際の物とは違って誇張され美化されて描かれているものであること Win, Win Kubernetesは 素晴らしいんやな Kubernetesは 素晴らしいんです 現場的に厳しい戦いになることは 往々にしてある 『あなたにKubernetesは必要ですか︖』 『多分あなたにKubernetesは必要ない』 『Kubernetes の導⼊時に考えるべきこと』
6. エンタープライズにおける Kubernetes 導⼊あるある 段階的な Cloud Native 化への道 • ネガティブな表現をしたが、現実問題として⼀息に Cloud Native 化など不可能 • 許容される変更量、リスク量は限られている Kubernetes を導⼊して既成事実を作ってから徐々に⽂化を変えていくのもまた道 Kubernetes Driven で Cloud Native Journey を歩み出す
7. ⾃⼰紹介 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
8. お客様事例 ⾦融系のお客様 サーバー間取引顧客 ブラウザ顧客 バックエンドシステム ランクAシステム 法⼈顧客 従業員 • 約20年の歴史を持つオンプレミスのシステム • ⾼可⽤性／低レイテンシが求められるランクAのミッションクリティカルシステム • Kubernetes(ICP) で本番稼動中 更 改 サーバー間取引顧客 ブラウザ顧客 バックエンドシステム ランクAシステム 法⼈顧客 従業員
9. お客様事例 l 完全にOSと統合、Immutable l ⾃動化オペレータで⾼度な⾃動化 l シームレスにKubernetesをデプロイ l 完全に⾃動化されたインストール l ワンクリックでアップデート l クラウドリソースを⾃動スケーリング ⾦融系のお客様 OpenShift＝Enterprise Kubernetes プラットフォーム への移⾏をご検討中
10. 本セッションのスコープ Cloud Native 化を進めるアプローチ Top Down, Bottom UP の両⾯からのアプローチが不可⽋ 営業 啓蒙 啓蒙 啓蒙 Bottom UP Top Down 本セッションのスコープ 開発部⾨・SIer ビジネス部⾨・お客様 マネジメント (意思決定者) 現場 指⽰ 相談 RFP 相談
11. AGENDA • Lessons Learned 1︓コストとスケール • Lessons Learned 2︓現⾏運⽤との兼ね合い • Lessons Learned 3︓モダナイゼーションへの道 • Lessons Learned 4︓チーム • まとめ
12. Lessons Learned 1︓コストとスケール
13. 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 を使う選択肢も無かった 使い⽅によっては税⾦が⾼くみえてしまう（特にインフラの集約性に着⽬した場合） 今回は税⾦を払うモチベーションはあまりないので、できるだけ節税したい
14. Lessons Learned 1︓コストとスケール ⽴ちはだかる税⾦の⾼さ • 4 vCPU • 16GB Memory Master Nodes Infra Nodes × 3ノード • 2 vCPU • 16GB Memory × 3ノード Worker Nodes × 40 Pod 削れない 槍⽟に挙がるのはここ トラディショナルな⽅法でもできるんじゃないの︖ 直近は要らないんじゃない︖ 今後 Kubernetes をやっていくなら必須なのだが… だが、今を乗り切る⽅法もあると⾔えばある
15. Lessons Learned 1︓コストとスケール ⽴ちはだかる税⾦の⾼さ 実際に、Kubernetes では泣く泣く削りました Master Nodes Infra Nodes Worker Nodes Promtail 開発環境 ステージング／ 本番環境 Shell kubectl get pod kubectl top pod Local PV 軽量な PLG を 選択 Grafana は⾮常に便利だった。 何かが起こったとき（障害・負荷試験等）に状態の推移をグラフィカルに⾒られるのは良い また、ログを各ホストサーバーへ取得しにいくのはやはり⾯倒だった。
16. Lessons Learned 1︓コストとスケール ⽴ちはだかる税⾦の⾼さ OpenShift では Infra Node の導⼊を検討中 Master Nodes Infra Nodes Worker Nodes 開発環境 ステージング／ 本番環境 • Red Hat のサポートが付く EFK を選択 (ただし運⽤のコアとはしない 後述) • Prometheus/Grafana はコアコンポーネントとして実質必須
17. Lessons Learned 1︓コストとスケール ⽴ちはだかる税⾦の⾼さ Lessons Learned • Master や Infra の税⾦に勝るある程度の規模の Worker ノードにしたい（マルチテナントも有効） • とは⾔え、最初からでかいクラスターから始めるのは難しい場合が多い • 将来像と合わせて投資ということにする • TCO で⽐較する • 現⾏のコストと⽐較する • 当たり前だが、ロギングやモニタリングのコンポーネントを⼊れないと後で⾟くなる • システムとしての重要性に加え、ビジネス⾯でも価値を訴求したい デイリーアクティブユーザー 都道府県別アクセス数 成約率 OS /ブラウザ別アクセス数
18. 最近の個⼈的疑問 EFK が特に重い EFK vs. PLG https://www.cncf.io/blog/2020/07/27/logging-in-kubernetes-efk-vs-plg- stack/ 将来的に OpenShift に PLG の採⽤はあるのか︖
19. Lessons Learned 1︓コストとスケール スケーラビリティに制限のあるオンプレ環境 基本的にHWを⾃由に増減させることはできなかった • ギリギリのリソースでやりくりする場合が多くなる • Requests を調整して押し込めるしかない tuned csi- sna… node- ca router-default eventrouter fluentd kiban a machine- config- daemon gr a… k u… node -… prometheus dns-default elasticsearch alertmanager Infra Node #1 Requests CPU: 98%（定常時は30%程のCPU使⽤率） • サービスレベルは気にしない (運⽤のコアコンポーネントにはしない) • まずは導⼊したい（⼊れることに意義） • Alertmanager は監視のコアコンポーネントとして⽤いる • 運⽤上クリティカルになるものは減らせない コアコンポーネントも減らせない サービスレベルで Requests を決める
20. Lessons Learned 1︓コストとスケール スケーラビリティに制限のあるオンプレ環境 リソースの調達には時間が掛かる • リソース追加には決済が伴うので、おいそれとリソース追加はできない • リソース⾒積もりをある程度精緻に⾏う必要がある • Core / Memory は Hardware Requirements として記載あり • OpenShift の場合 CR にデフォルト値として設定されている • ストレージ容量⾒積もりの⼿法 • アプリケーションログは現⾏をベースにサイジング • Elasticsearch は INDEX を張る関係上、ログ容量の3~5倍で⾒積もり • コアコンポーネントのログ／メトリクス量は検証クラスターで確認 検証クラスター（UPI）＠ 問題はストレージ容量の⾒積もり
21. Lessons Learned 1︓コストとスケール スケーラビリティに制限のあるオンプレ環境 Lessons Learned • ⼤前提として、余裕のあるリソース確保には尽⼒したい • そうは⾔っても確保が難しい場合もあるかもしれない • サービスレベルを決める • Requests / Limits を駆使する • スケーラビリティに制限があるなら、尚更 PoC の重要性は⾼まる • リソース⾒積もりは実際に動かしてみることが⼀番 • PoC をして Feasibility を⾒極める（リソース⾒積もりに限らず重要）
22. Lessons Learned 2︓現⾏運⽤との兼ね合い
23. Lessons Learned 2︓現⾏運⽤との兼ね合い 現⾏運⽤ソフトウェアとのインテグレーション 現⾏運⽤ SW(master) • プロセス監視 • メトリクス監視 • ログ監視 現⾏の運⽤⽅式 システムA 現⾏運⽤ SW(agent) 現⾏運⽤ SW(agent) 現⾏運⽤ SW(agent) システムB ・・・ システムN Kubernetesだけ 別のシステム監視とはいかないな ※許容されるリスク量・変更量の話も関係する 現⾏運⽤ SW(agent) 現⾏運⽤ SW(agent) • 統合監視基盤で運⽤を⾏っている
24. Lessons Learned 2︓現⾏運⽤との兼ね合い 現⾏運⽤ソフトウェアとのインテグレーション ソリューション（プロセス監視・メトリクス監視） Alertmanager Endpoint 現⾏運⽤ SW(agent) 現⾏運⽤ SW(master) 運管サーバー アプリケーション Pod, コアコンポーネント Pod カスタム Pod Master, Infra, Worker Nodes
25. Lessons Learned 2︓現⾏運⽤との兼ね合い 現⾏運⽤ソフトウェアとのインテグレーション ソリューション（ログ監視） 現⾏運⽤ SW(agent) 現⾏運⽤ SW(agent) 現⾏運⽤ SW(agent) 現⾏運⽤ SW(agent) 現⾏運⽤ SW(agent) 現⾏運⽤ SW(agent) 現⾏運⽤ SW(master) アプリケーション Pod Red Hat Enterprise Linux Worker Nodes • Worker Node には RHEL を採⽤
26. Lessons Learned 2︓現⾏運⽤との兼ね合い 運⽤⽂化とのせめぎ合い（インターネット接続） オンプレ環境はインターネット接続不可 お客様DC • オンプレ環境は基本的にインターネット接続不可 • 対象システムでインターネット接続を⾏った実績はなし OpenShift 4 のインストール⽅法 1. 直接接続⽅式 2. プロキシー接続⽅式 3. オフライン⽅式 ヤバイ、⾟いという 前評判を聞いた https://rheb.hatenablog.com/entry/openshift42-proxy-upi 絶対に通さないと⾟い 通さないといけない前提で話をもっていく
27. Lessons Learned 2︓現⾏運⽤との兼ね合い 運⽤⽂化とのせめぎ合い（インターネット接続） プロキシー接続⽅式 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を選択する必要があった
28. Lessons Learned 2︓現⾏運⽤との兼ね合い 運⽤⽂化とのせめぎ合い（インターネット接続） 実際の⽳あけドタバタ劇 僕 お客様 セキュリティ統括 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 mirror.openshift.com storage.googleapis.com/openshift-release *.apps.<cluster_name>.<base_domain> quay-registry.s3.amazonaws.com api.openshift.com art-rhcos-ci.s3.amazonaws.com api.openshift.com cloud.redhat.com/openshift FW申請書 ͍͟ɺΠϯετʔϧʂ ERROR xxx xxxxxx ERROR xxx xxxxxx ERROR xxx xxxxxx ERROR xxx xxxxxx ERROR xxx xxxxxx ࣦഊʂʂʂ
29. Lessons Learned 2︓現⾏運⽤との兼ね合い 運⽤⽂化とのせめぎ合い（インターネット接続） 実際の⽳あけドタバタ劇 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 で検証
30. Lessons Learned 2︓現⾏運⽤との兼ね合い 運⽤⽂化とのせめぎ合い（インターネット接続） 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 quay.io infogw.api.openshift.com cdn.redhat.com storage.googleapis.com subscription.rhsm.redhat.com 結果の申請書 • 開発・構築時の留意事項 • 現⾏のネットワーク⽂化がある場合は要注意 • リードタイムを短くする努⼒をするか、2,3回失敗しても⼤丈夫なスケジュール的余裕を持つべき • 今後の保守に向けて • マイナーバージョンアップグレードで接続先が増減することは容易に想像できる • アップグレード失敗時の対策として最低限、FWのログ取得は必須 • 合わせて、よりスピーディーなワークフローへの改善にも努⼒したい Lessons Learned
31. Lessons Learned 3︓モダナイゼーションへの道
32. 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回限りのプロセスとして実⾏する 対応（⼀部） 管理スクリプトの⼀部はコンテナイメージ内に同梱されコンテナ内で実⾏されるが、 ⼿動実⾏の運⽤⼿順も残っている
33. Lessons Learned ３︓モダナイゼーションへの道 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
34. Lessons Learned ３︓モダナイゼーションへの道 本当に必要な CI/CD • Kubernetes の早いライフサイクルに対応する必要がある (3ヶ⽉ごとのマイナーバージョンリリース、半年ごとのアップグレードの必要性) • 今までのN年塩漬けとは全く異なる考え⽅が必要になる • 本当に必要な CI/CD ってなんだっけ︖ • テストを⾃動化しましたが CI/CD じゃないないよね︖ • ⽬的とゴールを再確認しよう 【⽬的】 • 何らかの変更があってもサービスに影響が無いことを確認する 【ゴール】 • リリース・クライテリアを決める • それをできるだけ素早く簡易に実⾏できるようにする (⾃動化が絶対の⼿段とは限らない) 何らかの 変更 リリース・クライテリア ・ xxx ・ xxx ・ xxx 何かしらの⾃動化 簡易な⼿動実⾏ リリース https://access.redhat.com/ja/support/policy/updates/openshi ft OpenShift のライフサイクル
35. Lessons Learned ３︓モダナイゼーションへの道 本当に必要な CI/CD • どのレイヤーまでをスコープとするか Host OS Orchestration Container Container Container Container Container Runtime Automated Operations Manifest Manifest Package Manager Cluster / Application/ Developer Services マニフェスト〜アプリケーションの機能確認は当然やるでしょう 各種 Operator や Prometheus 等の Cluster Service はどうしよう 性能や可⽤性等の⾮機能確認はどうしよう ⾮機能どこまでやろう︖ インフラの CI やる︖ • どこまで⾃動化／パイプライン化するか ソースコード取得 ビルド 単体テスト パッケージ コンテナビルド 結合テスト アーティファクト登録 ステージングデプロイ パフォーマンステスト等
36. Lessons Learned ３︓モダナイゼーションへの道 Git 移⾏と Single Source of Truth Lessons Learned 本当に必要な CI/CD • 技術よりは仕組みやプロセスといったメタなことが障壁になりやすい • 活発に議論できるメンバーを3⼈以上集めたい • 現⾏の仕組みに詳しい⼈を巻き込むことも重要 • まずは「やってみる、やって⾒せる」ということが重要に感じる • 内容が良ければ、「⼀緒にやりたい」と⾔ってくれる⼈が現れる • Tool Driven でも⼤いに結構 • 導⼊してみると案外上⼿く動き出すってこともある メタな議論にも直地点を付ける（⾃戒）
37. Lessons Learned 4︓チーム
38. Lessons Learned ４︓チーム Kubernetes に適応したチームつくり OpenShift のサポート期間 • マイナーバージョンのサポート期間は約9カ⽉ • アップグレード期間も考慮すると半年ごとのアップグレード作業が必要 スーパーマンが⼀⼈は居ないと厳しい (本当は複数⼈ほしい) • 作りきったら終わりではない（≠塩漬 け） • 継続的な保守が不可⽋ https://access.redhat.com/ja/support/policy/updates/openshi ft
39. Lessons Learned ４︓チーム Kubernetes に適応したチームつくり お客様付きSEへのスキトラ お客様付きSE • 基本的なコマンド操作は習得済み（ kubectl get pod 等） • Kubernetes の仕組みはまだ理解不⼗分 僕 • 障害解析ができる • リリースノートが読める • ⼈に教えられる お客様付きSE お客様付きSEのみで Kubernetes の保守を回せることが理想
40. Lessons Learned ４︓チーム 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
41. Lessons Learned ４︓チーム Kubernetes に適応したチームつくり OpenShift スキル獲得 3. Operator ハンズオン https://github.com/Daiki-Kawanuma/kubernetes-operator-handson • OpenShift の設定は基本的に CR の適⽤で⾏われる • Operator の概念の理解が不可⽋ 『最⼩構成』の なんちゃって Operator 4. 社内勉強会の企画 • 最終的には Kubernetes を『教える側』になってほしいという期待 • ⼈に教えるには3倍の理解が必要 若⼿（1〜3年⽬）への勉強会を企画中
42. Kubernetes に適応したチームつくり Lessons Learned ４︓チーム Lessons Learned 2. いきなり全部を教えすぎない いきなり全部並べられても分かるわけがない 相⼿の知識レベルに合わせて“教え過ぎない”ことを意識する 勉強したい⼈が⾃分のレベルが分からない・その⼈のレベルにあったコンテンツが無いのが⾟い そもそもDockerの良い点や動かし⽅がわかっていない時にいきなりK8sの概念を聞いてもよくわからない コンテナに限らずそれぞれの⼈のレベルに合わせた説明やコンテンツは需要があるのかなと思う 1. ユースケースで刺す 概念や機能を教えても腹落ちしづらい（Kubernetes のジャズ的な性質） ユースケースに刺して機能を教えていく ⼀緒にハンズオンやりながら説明していただけたのはめちゃくちゃ良い あとは実際に動かせる環境が準備されているというのも良い 3. ⾃分の作業過程や情報源をオープンにする 考え⽅や思考過程を⽬に⾒えるところに置いておく 気づいてもらう⼯夫をする 何を知っているべきか、何ができればいいのかがわからない 欲しいのは結果を導くための途中経過 4. ⼿を動かさせる、⾃分でやらせる ⼿を動かさないと始まらない 運⽤引き継ぎフェーズで⼀挙にスキトラは絶対に機能しないのでやめた⽅が良い
43. • 本番稼動中だが、今のところコンテナ起因の障害は０ • お客様のモチベーションであったインフラコストは集約は達成できた • 既存運⽤⽅式とのインテグレーションも問題なく実施できた • Lift & Shift の “Lift” を成功裏に実施できた まとめ で、実際に Kubernetes 導⼊どうだったの︖ サービス⽬線 • リリース作業に要する時間が2時間から1時間に短縮できた • Kubernetes のリソースの集約化／抽象化という側⾯も開発の効率化に寄与した 開発⽬線 あるべき姿を定義しておけばあとはk8sが⾊々やってくれるというのは便利ですよね あとリソースの種類とかがわかっていればどこに定義が書いてあるかとかも探しやすいのがいいなと思います エンプラど真ん中のシステムに Kubernetes を導⼊したが、ちゃんと運⽤できてる
44. • ビジネスアジリティを求めるのか • 運⽤の⾃動化を求めるのか • 開発⽣産性の向上を求めるのか…etc まとめ コンテナ化第⼆章に向けて 今後、どんな Shift を描くか、Kubernetes に何を求めるのか • ビジネスアジリティの話をすると、今回削減できたのは全体のごく⼀部でしかない • 本当に効果を上げようと思ったら、改善できる箇所がまだまだ沢⼭ある やはり組織・⽂化と向き合うことは避けられない リリースまでに要する時間 今回の Kubernetes 導⼊で 削減できた時間 • チーム全体のスキルアップが必須だが、まずは⼀⼈⽬のスーパーマンの育成が急務 • とは⾔え、⼀⼈のスーパーマンに頼っていてはスケールしないので、スケールする仕組み作りが組織として必要 これから本格的に始まる Day2 Operation, Kubernetes を保守する⾟みと向き合う
45. まとめ コンテナ化第⼆章に向けて Kubernetes を活かすも殺すも今後次第 お客様と共に、全⽅位でやっていき
46. EOF Special Thanks • Satoshi Doi • Yusuke Urakawa • Hiromitsu Iwata • Kensuke Shigyo ご清聴ありがとうございました。