The invitation to Infrastructure CI
- 2. 中島倫明（Tomoaki Nakajima） @irix_jp ● 現在 ○ レッドハット勤務 ○ en-PiT pro 早稲田大学／SmartSE 講師 ○ 国立情報学研究所／TOPSE 講師 ○ 高度ITアーキテクト育成協議会（AITAC）講師 ○ 日本OpenStackユーザ会 ボードメンバー ○ 一般社団法人クラウド利用促進機構技術アドバイザー ● 過去 ○ en-PiT 東京大学 非常勤講師（S1/S2 月曜 2限 2014-2017） ○ 日本OpenStackユーザ会 会長（2013-2015） 2
- 4. 従来のインフラ作業 装置産業的なアプローチ ● 一度稼働を始めた装置の仕様は変わらないという前提 ○ 手作業主体の構築?運用 ○ 機器やソフトを直接（人が）操作 ○ ドキュメントベース 4https://www.needpix.com/photo/27320/factory-car-engine-assembling-production-manufacturer-workforce-auto-line
- 5. 現代のインフラは様々な変化の影響を受ける ● 構築当初はあらゆる変化を拒絶しようと考えたとしても、システム担当者の思いと は関係なく世の中は変化し、その変化の影響をシステムは受けてしまう。 ● 変化しない前提で作ったものを無理やり変えているから大変。 5 セキュリティホー ルがあったので、 パッチを適用した 要件の変更にとも ない、OSやミドル ウェアの設定が 変更された。 会社の買収やグ ループの統廃合 により利用者が増 えてリソースの増 設が行われた。 システムの初期状態 数年後 さらに数年後 法改正や新しい 社内ルールの整 備に伴い、新しい 監査ソフトウェア が導入された。 拠点の増減や連携 システムの増加にと もなって、ネットワー クの構成が変更さ せた。 この先にどの ような変化が あるのか？ その時の システムの姿 は？ 変化 変化 変化
- 6. インフラに影響を与える変化の要因は増え続けている 「変化」の例 ● セキュリティホールが見つかり パッチを当てる。 ● 特定機能に不具合があったの でソフトウェアのバージョンを上 げる。 ● EOLに伴い新しいソフトウェア に入れ替える。 ● システムの機能拡張に伴い新 規のミドルウェアを導入する。 ● 設定に不備があったので設定 を変更する。 ● 利用者が増加、減少したので システムのリソースを増減す る。 ● 会社の事業買収、売却に伴い ネットワークの接続先が変更さ れる。 6 1970年代 一部の基幹?社会 システム 1990年代 業務システム、 インターネット 2010年代 モバイル、センサー、生活、 エンターテイメント 社会全体 不確実性を 生み出す要因
- 7. 「変化に強い」インフラを作ろう Infrastructure as Code ● ITインフラに関わる構成定義や管理、変更管理や作業といった様々な事柄をプ ログラムが解釈するコードとして管理するすることで「変化が容易なインフラ」を作 るための考え方。 ○ ITインフラにアプリケーション開発で培われたノウハウ（不確実性への対処） を適用。 ○ 自動化は使われているが Infrastructure as Code の一要素でしかないの で注意。 7 目標 アーキテクチャ プラクティス 具体的な システム
- 8. もう一つの背景：インフラ効率化の考え方の変化 ● 従来???手作業中心 ● 自動化1.0???手作業を効率化する（ツールによるアプローチ） ● 自動化2.0???作業自体をなくしていく（仕組みによるアプローチ） 8 従来～自動化1.0 自動化2.0 人が「作業する」前提のプロセス 人が「作業しない」前提のプロセス
- 9. 作業からサービスへ ● インフラ作業ではなく、インフラサービスを開発して提供するアプローチ ○ 人と人の調整をサービス間の連携（API連携）に置き換える。 ○ 組織間のオーバーヘッドを削減する ● インフラエンジニアの仕事が「作業」→「開発」に変化 ○ 開発を支える仕組みとしての「インフラCI」の活用。 ○ 開発したサービス（機能）の「変化への対応」を最小の労力で行う。 9 自動化1.0 サービス化 連結 単純に手順を置き換える （簡単な箇所から小さく部分的な自動化） 作業をサービ ス化して別の 人に実行して もらう 小さな機能を連結して 大きな機能を作る テスト仕様書 パラメータシート 手順書 個別の自動化 ユーザー毎の権限管理 で必要なサービスのみ実 行 自動化 2.0
- 10. 新しいインフラの評価軸への対応 “一見単純な変更のために、合理的な範囲をは るかに超える時間がかかり、とても考えられな いくらい多くの問題が発生することがある。” ● 変更が大変なシステムは、一見システムが 安定稼働しているように見えても、全体とし ての品質が極めて低い。 ○ 従来の評価軸では高品質かもしれな いが、新しい評価軸を加えると品質は 低くなる。 10 安全に確実に動かす? コストを最適化する? ? 自分のたちの都合に関係なく世の中は変化する? ? 変化を前提とした管理手法の実践? 変化への対応する? ? インフラは落ちてはいけない。? ? できるだけ前提条件を固定して、不 確定な要素を排除する。? ? ? ? ? 購入して資産化するという前提の機 器利用。? ? 一度買ったら5年は持ちづづける前提 の活用方法。? ? ● IaCやインフラCIはこれらの変化に 対応するための技術
- 11. インフラCIでやること 11
- 12. 自動化の進め方 ● 今までの作業を自動化する → Playbookを書く ● 自動化した作業をサービスとして提供する → AWX/Towerでボタンにする 12 LB 閉塞 事前 バックアップ モジュール 更新 事後 バックアップ LB 開放 動作確認 作業の 調整＆確認 作業の 調整＆確認 サーバー チーム アプリ チーム NW チーム 手作業 or 自動化1.0 作業前の 準備 実作業 LB 閉塞 事前 バックアップ モジュール 更新 事後 バックアップ LB 開放 動作確認 作業の 調整＆確認 サーバー チーム アプリ チーム NW チーム 一部サービス化された状態 サービス 化された 作業 NWチーム が登場しな くなる ここを作る
- 13. 悩みどころ ● 目の前の作業をAnsibleで自動化してサービス化する ○ 実はそんなに難しくない。 ● 実際にやってみると出てくる悩み ○ このPlaybookって、別の環境でも動くんだっけ？ ○ このPlaybook（半年前に作ったやつ）って、今そのまま動かせるんだっけ？ ○ Ansibleをバージョンアップしたけどこれって動くの？？ ○ 操作対象のOSがバージョンアップされたけどそのままでちゃんと動く？ ○ バグがあったから直した、機能を足した、今までの処理に問題は出ないよ ね？？ 13 自動化側が変わらなくても、取り巻く環境は変わっていく。
- 16. CI環境の整備 ● コード管理(git) ● CIツール(jenkins, gitlab-ci, travis, etc) ● テスト環境(コンテナ、VM、物理マシンなど) 16 github travis-ci コンテナ (テスト環境) Action Test テスト 条件 デモ環境 ● https://github.com/irixjp/sd2018-ansible-ci ● https://travis-ci.org/irixjp/sd2018-ansible-ci
- 17. まとめ ● インフラCIが必要とされる背景 ○ 安定稼働＋「変化への対応」が求められる ■ 変化にコストがかかりすぎるシステムは品質が 悪い ○ 作業からサービス（開発）へ ● インフラCIでやることは簡単、やることも増えない ○ 今までやっていたことが形を変えるだけ ■ これが大変だと感じるのは、本来やるべきこと をやってなかっただけ説 ● ただし万能の手法ではない ○ ２次元で評価されるシステム（自動化1.0）では使い所 が限られる。 ● インフラCIを成功させるヒント ○ 故に上兵は謀を伐つ、其の次は交を伐つ、其の次は 兵を伐つ、其の下は城を攻む、攻城の法は、已むを 得ざるが爲なり。 17