1
IIJ Bootcamp 2022
DevOps Overview

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

18
IaC（Infrastructure as Code）、CI/CD

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

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

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

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

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

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

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

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

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

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

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

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
IIJ-BKLT999-0001