Infrastructure as Code によるインフラ構築の 自動化により、オペレーションミスを防ぐ仕組みづくり

私自身の経験を元にインフラエンジニアとしての
技術的負債を考え、Infrastructure as Codeによる
インフラ環境の構築・運用の自動化にたどり着き
解決に至るまでの工程をご紹介致します。

Transcript

1. Infrastructure as Code によるインフラ構築の 自動化により、オペレーションミスを防ぐ仕組みづくり RAKUS Meetup Osaka #9 株式会社ラクス 山村祐太
2. 自己紹介 • 所属・氏名 • 株式会社ラクス 開発本部 大阪インフラ開発課 • 山村祐太（やまむらゆうた） • 業務内容 • 2018年4月より自社サービス「ChatDealer」の運用保守を担当
3. ChatDealerとは • 「チャットディーラー」は、Webサイトや社内ポータルなど にチャットウィンドウを設置して、問い合わせ対応を 行うことの出来るWebチャットツールです。
4. 話すこと • 私自身の経験を元にインフラエンジニアとしての 技術的負債を考え、Infrastructure as Codeによる インフラ環境の構築・運用の自動化にたどり着き 解決に至るまでの工程をご紹介致します。
5. インフラエンジニアとしての 技術的負債について考えてみた
6. • コーディングレベルの負債 • バージョンアップするべき言語やライブラリなどの負債 • 負荷が考えられていない実装による負債 • トレンドが変わって乗り換える必要が出てきた場合の負債 • 共有不足で実装内容のブラックボックス化による負債 （https://www.orangeitems.com/entry/2018/03/23/121457より引用） そもそも、インフラの技術的負債って何?
7. 共有不足で実装内容のブラック ボックス化による負債を考える
8. 私自身にあてはめて考えてみた • 担当商材で、過去にDocumentの更新漏れにより サーバ構築の途中でエラーが出て、原因調査特定に 時間を要したことがあった
9. Documentの更新漏れを 防ぐには?
10. タスク管理システムとして Redmineを活用してみた!
11. • Redmineプロジェクト管理ができるオープンソフトウェア • やるべき作業を記録・管理して社内で情報共有が出来る • チームでプロジェクトを進める場合に誰がいつまでに 何をやるのか?現在どのくらい進んでいるのか進捗状況を 計画通りに進むよう支援してくれるツールとなります。 Redmineとは （画像:https://redmine.jp/overview/より引用）
12. • Documentなどの更新漏れが発生しないようにチーム 運用として、Redmineを活用した以下の運用を行った - 本番環境に変更を加える際の作業手順などは課内で レビューを実施!この時にDocumentの更新が必要か どうか判断を行い必要であれば、taskとしてチケット作成 - 週次でMTGを開催、ガントチャートによる全体 スケジュールの確認を行い、各自taskの進捗を 報告及び、相談を実施! Documentの更新漏れを防ぐ仕組み作り(1/2)
13. • 以上の結果、タスク管理システムのRedmineを活用して、 Documentの更新漏れを防ぐ仕組みを実現! 合わせて、taskの見える化、業務成果、リードタイム なども明確化された! Documentの更新漏れを防ぐ仕組み作り(2/2)
14. オペレーションミスが原因で、 サーバの構築が上手くいかない 問題が発生!
15. • Documentを元に手動で、サーバ構築を行っていたが、 これを構成管理ツールなどを活用して、作業の自動化を 行えば、オペレーションミスによる問題が防げる ※ただ、構成管理ツールを使うことで、手順をコード化する ことにより対応できるメンバーが限定され、属人化に ならないように合わせて部内で、構成管理ツールに対して のスキル向上の推進も行う必要がある 手動作業部分の自動化を考える
16. • サーバ、ミドルウェア、バージョン情報などの 構成管理を補助してくれるソフトウェアのこと 構成管理ツールとは?
17. • サーバのセットアップなど、手動でのコマンド操作などを 自動化することが出来る • サーバの設定情報などを一元管理が出来る • 1度の操作で、同時に複数台のサーバ構築や設定が出来る • コード作成時に冪等性(べきとうせい)を考慮出来る 構成管理ツールで出来ること
18. • 冪等性(べきとうせい)とは、ある操作を一回行っても 複数回行っても、同じ結果を得られるということ 冪等性(べきとうせい)について
19. • 以下理由を元に、「Ansible」の選定に至る。 - エージェントレスのアーキテクチャ - モジュールによる拡張性の高さ - 課内では、既に構成管理ツールとして、Ansibleを採用 していることもあり、Ansibleに対してのノウハウも 蓄積されていた 構成管理ツールの選定
20. • Red Hatが開発するオープンソースの構成管理ツール • PlayBookというYAML形式のテキストファイルに定型業務を タスクとして、記載して、それを元にAnsibleを実行させる ことにより、様々な処理を実現出来る Ansibleとは 構築手順 (Document) YAML形式で PlayBook作成 (コード化) Ansible実行! Management Server
21. • 手作業部分のコード化を行うことで、作業自動化が進み オペレーションミスを防ぐ仕組みを作ることができる • サーバに設定されている情報などを構成管理できる • クラスタなどの大規模サーバを構築する際、Ansibleを 活用して、サーバを並列で構築することにより、 作業時間が大幅に短縮される Ansible導入の目的
22. Ansibleを活用! 手動オペレーションのコード化を実施
23. • 以下の手動オペレーション作業をPlayBookに落とし込む - ディレクトリの作成 - ファイルを配置 - パーミッション権限の設定 - シンボリックリンクの設定 - パッケージのアンインストール及び、インストール - アプリケーションの設定情報反映など PlayBookの作成
24. ディレクトリ構成イメージ • ディレクトリ構成などは、Ansible Best Practiceを元に作成 （参考URL:https://docs.ansible.com/ansible/2.9_ja/user_guide/playbooks_best_practices.html）
25. Ansible導入での生産性 向上について
26. • Documentを元に、1クラスタ辺り、十数台のサーバを 手動オペレーションで構築した際の工数とAnsibleを活用して、 手動オペレーション時と同様のサーバ台数を構築した際の工数比較 生産性向上の効果 600分 60分 手動オペレーション Ansible クラスタ構築作業工数 作業工数90%削減達成!
27. Serverspecでテスト自動化を 行えば、さらに生産性向上! ※今後実装予定
28. • オープンソースの自動テストツール • サーバの状態をテストするためのフレームワーク • Serverspecを利用することで、意図した設定がサーバに 反映されているか確認することができる Serverspecとは?
29. • 以下の手動で実施していたテスト項目などをServerspecを 活用し、テスト自動化を行う - 各サービスの起動状態 - 指定ポートがListenしているか - 作成したユーザ/グループが存在するか - ディレクトリのオーナーとパーミッションが正しいか - 指定したパッケージがインストールされているか - 指定したミドルウェアバージョンがインストールされて いるか・・・etc Serverspecでテスト自動化
30. まとめ
31. まとめ • 以下の対応を行うことで、Infrastructure as Codeによる インフラ環境の構築・運用自動化を推進することが出来た - タスク管理システムのRedmineを活用して、Documentの 更新漏れを防ぐ仕組みを実現!結果として、taskの見える化、 業務成果、リードタイムなども明確化された - オペレーションミスを防ぐために、手順の自動化を構成管理ツール 「Ansible」を活用して、生産性の向上が実現! ※合わせて属人化にならないよう部内で、Ansibleに 対してのスキル向上の推進も行った - Serverspecなどで、テスト自動化を行えばさらに 生産性の向上が見込める!
32. ご清聴ありがとう ございました