Edited at

Operation as a code 実現に向けた運用統合ライブラリの作成活動について

この記事は 富士通クラウドテクノロジーズ Advent Calendar 2018 の10日目です。  

昨日は @khamanaka さんの エンジニアリングマネージャーとして1 on 1で使ってきた「好き/嫌い/得意/苦手のマトリクス分析」 でした。


概要

インフラSRE部 新卒2年目の@jinshiです。

タイトルで勝手に「Operation as a code」とつけてますが、運用に必要なオペレーションをコードとして表現しようという活動です。

私のチームではSRE活動の一環として、運用のオペレーションをコードで表現するために運用統合ライブラリーなる物を作成する活動をしています。

まだ製作段階ですが本記事ではその統合ライブラリーについて紹介したいと思います。


背景

私のチームでは日ごろ様々なサービスを管理・運用してきました。

今までも増加する管理対象に対応するために個人、チームレベルでは運用を効率化するために手動で行っていた作業をスクリプト化する活動は一部でありました。

たとえば構築作業などは一部分はツール(ansible)などを使用してコードとして実現されています。

しかし初期の段階でこれらスクリプトの設計や規約などを設けなかったため様々な問題がでてきました。


  • 特定のインターフェースからしか実行できないコードがあり、違うインターフェースから実行するには同じようなロジックを複数のファイルに書く必要がある


    • 例えばansibleとcliから同じコードを実行したい場合など



  • コードがいろいろなプロジェクトに分散しており管理が煩雑になる

  • etc

またこの問題点に加えて、まだスクリプト化されてない運用手順も多くあり日々複雑で肥大化する管理対象に耐えられなくなる可能性がでてきました。

このような問題を解決するために統合ライブラリーを作成する活動がスタートしました。


統合ライブラリーで実現したいこと


効率化


  • 手順がアップデートされた際の共有


    • 更新されたコードを実行ノードに配布するだけになる



  • テスト・CI(今まで手順書などを人が確認していた部分がCIで自動化できる)


    • コンポーネントのアップグレードや入れ替えで以前の運用が継続できるか検証が必要だが工数が大きかったが、CIなどの取り組みにより素早くできるようにする



  • 運用オペレーションの自動化(人が作業をする必要がない状態)


サービス品質


  • 障害が起こった際の対応スピードの向上

  • CI(テスト自動化)によるオペレーションの信頼性の向上

  • 効率化により新サービスや新機能に注力できる時間を増やせる


非属人化


  • 運用オペレーションの非属人化・運用ノウハウ伝播の効率化


    • コードを見ればオペレーションのロジックが追えるので今まで個人の頭の中にあった運用ノウハウをチームメンバーが知れるようになる




設計

大きな設計の概要図は以下になります。


設計.png


アダプター


  • 各インターフェースに一つ作成する形になると予想しています。

  • controllerの情報を読み取り各インターフェースから実行できるようにします。

  • 正確にはライブラリの外の機能になりますが実際に使用するにあたっては必要になってくるので、実装予定です。


    • 今考えてるところですと、CLI, APIサーバーの自動生成, Ansible モジュールの自動生成あたりを考えています。




Controller


  • 実際にロジックをかいていくとこです。

  • また入力、出力の定義、バリデーション機能などを含める予定です。

  • 実際にサービスを操作するためのDAOを呼び出します。

  • 1 controllerはDAOの1操作(1API)に対応させようと考えています。複数のサービスの操作が必要な場合はコントローラーが他のコントローラーを呼ばせるように規約を作ろうと思います。


DAO


  • 各サービスのAPIへのアクセスなど、各サービスの操作をする部分です。


課題

実際に規約をコードとして表現する部分が難しいところです。

コードをレビューする際に実際に動作するコードであるかの確認はあたりまえですが、可読性や上で示した設計通りになっているかなど規約を確認する必要があります。

その確認を毎回人がするのは大変で時間がかかるためコードとして確認できる仕組みを実現できするのが理想です。

しかしあまりに強い規約や、規約に従わせるために無理な実装があるとチームメンバーの開発の負担になります。

オペレーションをコード化したチームが「コードを書くコストが思った以上に高く結局手動より時間がかかってしまっている。」なんていう例も聞いたことがあります。

またその場合他チームへの展開もしにくくなってしまいます。

最初はチームに閉じて利用していきフィードバック、メンバーの使用感や意見をもらいつつ設計を変更していく必要があると思っています。


まとめ

まだ実際に実装は終ってはいないですが、近日中に実際に統合ライブラリを利用してのオペレーションを予定しています。

またチーム内での実績が積め安定した利用が見込める場合は他チームへの展開などをしていきたいと思っています。

特にアダプター部分を強化していくことによりロジックを考える部分に集中ができ他のチームが利用した際にもメリットがある内容になるのではないかと思っています。

11日目は@pachicourseの 「0知識からのAnsible 詰まった所&覚えておきたいと思ったところ列挙編」です!

タイトルを見た感じ弊社の違うチームもAnsible使ってるようですね。本記事の活動が他チームにも広がるとうれしいです。