IIJ社内で行われている新人向けハンズオン勉強会「IIJ Bootcamp」で行われた "DevOps Overview" です。 開発者と運用者がうまくいくには。効率的な時間の使い方。自動化の話。Kubernetesなどを紹介します。 ▼IIJ Bootcampについて IIJ Bootcampとは、様々な技術に触れることを目的としたIIJ社内で行われている新人向けハンズオン勉強会です。 https://iij.github.io/bootcamp/ 各技術が誕生した経緯・歴史、ほかの技術と比較といった知識を得るためのきっかけとして、さまざまな言語・フレームワーク・ツールに触れて実際に動かすハンズオンを行っています。 カリキュラムにはハンズオンだけでなく、「overview」として技術ジャンルの全体像や歴史などを紹介する回も設けています。

1. 1
IIJ Bootcamp 2022
DevOps Overview

2. 2
⾃⼰紹介
Inetnet Initiative Japan
SRE推進部 部⻑ ⽥⼝ 景介
IIJにSREを⽴ち上げた発起⼈。
少数の専任とサービス事業部⾨から集められた総勢18名の
エンジニアで編成。プラットフォームの技術開発の場であり、
事業部⾨とインフラ部⾨の交流の場でもある。
#cloud #kubernetes #roadbike #udon
#f1

3. 3
ビジネスの成功と時間の使い⽅

4. 4
⾼尚な話と卑近な話をします

5. 5
ビジネスを成功させるために求められること
• スピード
• 市場のニーズを満たすビジネスを時期を外さずに⽣み出す
• 品質
• お客様に信頼されるサービスを提供する
• 技術
• 競合と戦い、勝利する

6. 6
時間を効率的に使う
利益
を⽣み出す
ための時間
• どちらも重要で、要不要の⽐較ではありません
• ビジネスを成⻑させるための時間配分
維持
するため
の時間

7. 7
メンテナンス、
サポート、障害対応
開発、機能追加
規模の拡⼤
• ビジネスが拡⼤するにつれ、維持に使う時間が増える
• ⼯夫しない限り、アップデート速度は低下していく
時間の経過とともに望む形ではなくなっていく

8. 8
引⽤︓ http://www.pasonisan.com/pc-cpu/00-column-clock.html
業界によらず似たようなもの
CPUは歩留まりを⾼めることで⽣産性を向上させる

9. 9
我々のサービスに例えるなら
歩留まりが低い ≒ サービス維持に⼤量の時間が必要

10. 10
⽣産性を⾼めるには
最⼩限の労⼒、最⼩限の時間で
⼀定の品質が保証されるようにしたい

11. 11
「⾯倒臭がり」はいいこと

12. 12
• 同じことを繰り返し作業するのはつまらない
• ⾯倒くさい
• 退屈なことはやりたくない

13. 13
• ミスを犯すと、リカバリに時間を要する
• 再発を防ぐために、多くの時間を検証に当て
るようになる
• ミスを犯すようなことをしたくない

14. 14
• 何度も繰り返す
• ⼀度の失敗も許されない
• 簡単でも、頻度の⾼い作業を正確に繰り返すのは難しい
• ⼗分時間がかけられるなら、⼀度だけの難しい作業の⽅がまし
• システムに変更を加える
• 副作⽤を⾒逃さずに、複雑なシステムに⼿を加えるのは難しい
• 変更するとき、元に戻せることを保証するのは難しい
「何回繰り返しても、必ず成功する」は難しい

15. 15
⾃動化で改善したい
• ⼈間は必ずミスを犯す
• ⼈間の介⼊を最⼩限にしないとミスは減らない

16. 16
⾃動化は難しい
• 作業を⾃動化するのは、多くの場合難しいことではない
• しかし、結果の確認まで⾃動化するのは⾮常に難しい
• だからといって、確認を⼈間がやっていたら効果は限定的

17. 17
「何回繰り返しても、必ず成功する」のための⾃動化
• ⾃動化は難しい。100%の⾃動化は⾮現実的
• しかし、乗り越えて実現しないとこの式は成り⽴たない
利益
を⽣み出す
ための時間
維持
するため
の時間
＞

18. 18
IaC（Infrastructure as Code）、CI/CD

19. 19
何を⾃動化する︖
• システム運⽤
• 宣⾔的な構成管理
• 構成情報と実環境の整合性維持
• ソフトウェアのリリースサイクル
• ソフトウェアの開発の効率化
• ソフトウェアの品質向上

20. 20
システム運⽤
プロビジョニング
コンフィグレーション
デプロイメント
モニタリング
• システムの正常性を確認
• キャパシティをチェック
• アプリケーションをリリース
• バグや脆弱性の修正
• 機器やOSの設定
• ソフトウェアの構成
• サーバ、ストレージ、ネットワー
クの調達、構築

21. 21
ツールを活⽤して運⽤を⾃動化
プロビジョニング
コンフィグレーション
デプロイメント
モニタリング • prometheus
• kubernetes
• docker
• ansible
• terraform

22. 22
ソフトウェアのリリースサイクル⾃動化
• ソフトウェアの設計、実装を⾃動化するわけではない
• 開発したソフトウェアを運⽤環境へリリースするまでの⼀連の作
業を⾃動化する
PD
（Progressive Delivery）
CD
（Continuous Delivery）
CI
（Continuous Integration）
• ビルド、テスト、アーティファクトの⽣成、
レジストリへの登録
• デプロイメント
• チェック
• リリース
• ロールバック

23. 23
CI, CD, PD
• CI, CD, PDの⾔葉の定義はツールの発展に伴い何度も変わってきた
• 当初、CIがすべてのライフサイクルを担っていた
• CIからデプロイメントが独⽴し、CDとなった
• CDからリリースが独⽴し、PDとなった
• PDは最近提唱された考え⽅で、まだあまり⼀般的ではない
• 新しいコンセプトの提⽰ではない
• 単にソフトウェアをリリースするだけでなく、安全にリリース
するための各種⼿法を実践する
• リリースエンジニアリングの実践

24. 24
よくある⾃動化されていない運⽤の課題
• 現在のシステムの状態を⼗分に把握できていない
• 変更を加えたときに何が起こるのかわからない
• できる限り⼿を加えたくない
• ソフトウェアのアップデートや設備の更新は不可⽋
• 確認ができないまま、更新⼿順を机上で確定
• 更新後、問題が発⽣してもロールバックできない

25. 25
優れた運⽤の⾃動化とは︓宣⾔的構成管理
• 現在のあるべき状態を定義し、その状態が維持される
• 状態を更新するときは、現在との差分が判定され、必要な設
定だけが反映される

26. 26
優れた運⽤の⾃動化とは︓ Kubernetes, Ansible, Terraform
• ⼈は「あるべき状態」を定義するだけ
• Kubernetesならばマニフェストを定義
• Ansibleならばプレイブックを定義
• TerraformならばHCLで定義
• 何を設定すれば「あるべき状態」になるのかはツールが判断する
• 「あるべき状態」から逸脱したら、ツールが⾃動的に復旧を試み
る

27. 27
Kubernetes
• googleが開発したプラットフォームBorg（⾮公開）をベー
スに開発されたオープンソースのコンテナオーケストレータ
• サーバサイドシステムの設計や運⽤の概念が根本的に変わる
• 標準的なプラットフォームとなることはほぼ確定的

28. 28
IKE（IIJ Kubernetes Engine）
• SREが開発、運⽤しているKubernetesベースの次世代プ
ラットフォーム
• 全⾯的に宣⾔的構成管理を採⽤
• まだすべてのシステムがIKEにのっているわけではない

29. 29
- 29 -
1. アプリケーションをデプロイ
2. ストレージボリュームを作成
3. グローバルアドレスの払い出し
4. ロードバランサを設定
5. DNSにリソースレコードを設定
6. サーバ証明書を発⾏
7. モニタリングを設定
8. 監視ルールを設定
9. アラート通知を設定
10.ログ収集を設定
 Kubernetes と IKEの違い
• Kubernetesだけでできるのは「1. アプリケーションのデプロイ」だけ
• それ以外はIKEとして整えた環境があって実現する
$ kubectl apply –f .

30. 30
- 30 -
 IKE エコシステム
• IKE （IIJ Kubernetes Engine）
• IKE Gate
• IKE Monitoring
• IKR（IIJ Kubernetes Registry）
IKE
Cluster EAST
IKE
Monitoring
IKE
Cluster WEST
IKE Gate 顧客 A
IKE Gate
IKE Gate 顧客 B
HOP
Internet

31. 31
IIJ-BKLT999-0001