はじめに
初めまして。社内のエンジニア組織主体でこの度記事の連載を始めることになりました、衞藤です。
こちらの連載記事では「FJCTQualityUp」と題して、富士通クラウドテクノロジーズ株式会社（以降FJCT）のエンジニアに「FJCTのサービス品質向上のために何をしているのか」を様々なトピックを話題に社員にインタビューをしていきます。
エンジニアの生の声が、これからエンジニアを目指す方、今まさに課題解決に取り組んでいる同業者、その他大勢の方にとって参考になる、明日からの実践のきっかけになることを願っています。
第一回：インフラの構築自動化ツール「Ansible」を通した運用の安定
まずは自己紹介
衞藤：インフラの構築自動化ツールとして有名な「Ansible」の社内利用について、ニフクラのプラットフォームでIaaSOpsを担当するチームに所属する二人にインタビューをさせていただければと思います。どうぞよろしくお願いいたします。
大橋：よろしくお願いします。プラットフォームSRE部IaaSOpsチーム 大橋です。入社5年目の社員になります。今関わっている業務は運用や構築の自動化等が主で、他にも社内APIゲートウェイの開発チームにも加わったりしています。
鈴木：プラットフォームSRE部 鈴木です。自分は大橋さんより1年先に入社したので入社6年目になります。今やっている仕事の一つとして、実は「良くないAnsible」の書き直しをやっていて、OSやミドルウェアの最新化に伴ってこの「良くないAnsible」を書き直すという業務をやっています。他にはZabbixとか監視のプロジェクトにも関わっています。
そもそも「Ansible」とは
衞藤：そもそものお話になるんですが、今回お聞きしたい「Ansible」についてご説明いただけますか。
鈴木：いわゆる「構成管理ツール」ってやつですね。サーバーに対してAnsibleを実行するとYAMLで記述された設定ファイルの一連の動作に従って、ソフトウェアやアプリのインストールやそれぞれの設定を自動で行ってくれるツールになります。
鈴木：こういうサーバー作りたいなあって書いて実行したら、サーバーができるみたいな。
IaaSOpsチームでどのようにAnsibleが使われているのか
衞藤：なるほど、ではニフクラを提供する上でどのようにAnsibleが必要になってくるのかお聞きしてもよいでしょうか。
大橋：例えば、ニフクラ IaaS の機能を実現するためのサーバーというものが裏側にいるんですが、サーバーによってそれぞれの仕事や役割があります。これらのサーバーには役割に応じたミドルウェアやソフトウェアモジュールが必要で、そんなサーバー群をすべて手動で作成するのはとても大変なんですよね。必要なソフトのインストールや設定の適用などを手作業でポチポチやるのは超大変ですし、それだけで30回以上もメンテナンスをしなくちゃいけない。
大橋：ここでAnsible を使うと、各役割のサーバーがどんな設定やソフトを持っていれば良いかを構成管理ファイルで定義した上で、一気に作って管理することができるんですよ。そういった背景があってIaaSOpsチームではサーバーの構成管理にAnsibleを利用しています。
大橋：使うことのメリットとしては、アプリのバージョン等をwikiやExcelで管理する古の伝統的な手法をとらずにYAMLに記述する形で構成管理を実行できるようになります。
Ansibleを使う前は環境構築を他社に委託していた
衞藤：確かに、サーバーの設定ってOS毎に違ったりして手作業だと人的ミスも発生しやすいですよね。ニフクラではどういった経緯でAnsibleを使った構成管理をするようになったんでしょうか。
鈴木：実は、自分はAnsibleを使い始めるタイミングでチームにいました。
鈴木：鈴木：昔はニフクラはサーバーの構築や設定をアウトソースしていて、委託先にはChefという他の構成管理ツールを使っていただいていました。FJCT側から委託先へ「このようなサーバーを作ってください」と依頼したら作ってくれるという体制です。
鈴木：ただ、その体制に不都合もぶっちゃけ多くてですね。ちょっとした検証環境を作りたいときにも毎回依頼を出す必要があって柔軟な対応が社内で取れなかったんですね。他にもサーバーの良くない設定が見つかってその箇所を変更したいとなった際に都度依頼を出す必要があった。こういった課題に対応するべくAnsibleの利用を検討し始めたという経緯になります。
大きなシステムに対する構成管理になるほど気を遣った設計が必要
衞藤：そういった経緯があったんですね。それでは、実際に使い始めてみるとわかってくるAnsibleを使った構成管理での注意点ってあるんでしょうか。
大橋：実はAnsibleって設定値の持ち方って超自由で、かなりいろんな所に変数とかを設定できる。あるホストの設定値がAとして、Aの設定値は5みたいな書き方ができるんですけど、その設定の確認方法が結構めんどくさい。そのホストに適用される最終的な変数をパッと出す手段がなくて。
大橋：なので、そのあたりは結構気を遣うところです。秩序だった構成をとらないと「ここの変数はどこから参照してるんだっけ」「なんのためにあるんだっけ」「他から上書きされないんだっけ」といったことに気を遣う必要が出てくるんですよね。
大橋：特に規模が大きくなっている、既に大きいシステムに対して構成管理を当てはめようとすると気を遣った設計をしないといけない。
鈴木：Chefから移行した当初は結構スピード重視だったりとか。まあそもそも設計という設計ってのが無かったので、その頃からまあ継ぎ足し継ぎ足しやってた感じがあって。無駄に肥大化したりとか。
鈴木：変数もバラバラ、どこにあるかも分からない。ずっとやってる人には分かるけど、後から来た人には全然分からないとかそういう状況になっていました。
鈴木：提供しているサーバーの種類もそもそも数十種類でサーバー自体も数百台とか。その状況でインフラも結構複雑な場合もあったりしたので、継ぎ足し継ぎ足しでやっちゃって来たので結構見にくい状況になっているんですよね。
鈴木：それを改善するために、今は改善活動をやっているところです。現在使っているAnsibleをより使いやすい、メンテナンス性が高いものを作ろうと。
Ansibleでの構成管理の品質を担保するには
衞藤：大きなシステムの構成管理になってくると設定には最新の注意を払う必要がありそうですね。お話を聞いているとAnsibleを使っても環境構築がうまくいっているかはチェックする必要がありそうだと思いました。この辺りはサービスの品質にかなり関わってきそうですが、どのように確認されるのでしょうか。
鈴木：サーバーを構築した後にサーバーのあるべき姿をテストするツールのようなものがあって、それを実行するという手法が最もポピュラーですかね。
鈴木：それか、我々がサーバーを構築する目的はIaaSの新しい環境を提供したりすることなので、その新しい環境でAPIを全部流してみてそれらがすべて正常に完了すればサーバーの構築も完了しているということになると思います。
大橋：FJCTの社内では、マニフェストプレイブックと呼ばれるあるべき状態になっているかの冪等性を確認することに重きを置いているんですよね。例えば、Ansibleの各要素を実行した後には必ず「OK」や「Changed」が流れてくることを確認して、正しい状態になっているかを確認するような形です。
大橋：Ansibleを使う際には、提供されている便利なモジュール以外にも自分たちで処理をShellで記述したりすることができます。そのあたりをやり始めると冪等性が崩れがちなので気をつけています（※Shellで記述したモジュールの実装が誤っていると、正常終了しても冪等性が担保されない場合がある）。
大橋：もちろん、設計段階で冪等性が崩れないことが担保されていれば、Ansibleが正常終了している確認までで終わるチームも多いです。慎重にする場合はAnsible spec等でテストをする必要があります。もちろん、Ansible specを使う使わないにしてもきちんと確認はできると思いますが、うちのチームは基本的にAnsible specを利用していますね。
大橋：こういった風に冪等性を意識するのは理由があります。変な設定や構文の矛盾があったりするとメンテナンスを実行する際にAnsibleが止まってしまう。冪等性が担保されていないともう一度実行した際に想定外の挙動をしてしまうので、その日のメンテナンスが中止や長引くことになってしまう。そういったことを防ぐために開発の段階でテストをしたり、レビューをしたりしていますね。
今後への取り組み
衞藤：冪等性を意識するという部分は安定した運用を実現する上で重要な視点ですね。これまでは過去から現在までの取り組みをお話いただきましたが、これからの未来に向けての視点でIaaSOpsチームでAnsible関連で取り組んでいきたいことはありますか。
大橋：IaaSOpsの開発チームはこまごまとした開発が多いんですが、きちんとしたデプロイを記述できていなかったりします。管理ノードに対しては、ダブルチェックをして作業を注意深く行うみたいなことをやっていてできるだけこれらをなくしていきたいですね。大きなサービスの構成管理とかはやっているので、そういった細切れのサービスの環境とか修正について構成管理のツールを当てていければと。
大橋：そういった細々とした作業は勝手に自動でやってくれるようになってほしいですよね。環境にある設定を置くだけの作業は基本的にはつまんないので、楽しい自分の仕事をやっていけるようにしていきたいです。
衞藤：ある種こまごまとした家事の自動化みたいな感じになりますかね。部屋のあるべき状態を定義して、自動でその状態を保ってくれるみたいな。毎回そういった作業をするのってすごく手間ですし。
鈴木：定常的な作業の部分はどんどんAnsibleに落とし込んで自動化していきたいですね。
鈴木：今作っている部分の課題としては、OSやミドルウェアが最新のものだと対応するモジュールが無かったりするので自分で冪等性を担保しながらコードを書く必要があります。それに加えて、将来的に環境が壊れないような設計をするということも意識している部分ですね。
鈴木：気を付けないと昔の整理されていないAnsible環境に戻ってしまうので。
鈴木：結局私たちがやっていることの結果がユーザーがまず触れる場所になるので、我々が管理しているAnsibleは重要なものになってきます。
大橋：あと、これからやっていきたいことだと、構成情報をグラフィカルに確認できるようにするようにしたいですね。以前neo4jというグラフィカルなDBを使って構成管理を検討したんですけど最終的には見送りになりました。その時にできなかったような、どこにどのネットワークがつながっている等の情報が視覚的にわかりやすく表示できる仕組みが欲しいです。
大橋：実はIaaSで定義しているAnsibleの設定ファイルはすごく大きくて、テキストファイルであるにも関わらず4.2MBくらいあるんですよ。GitLabからPullしてくるだけでも30秒程度かかっちゃう。そんな状態なので、GitLabをWebブラウザで開いて確認してもホストの個別設定が表示されないんですよね。大きすぎて。
大橋：こう、構成に関する情報をパッと見たいって時にいちいちターミナルを開いて確認しなければいけないので、グラフィカルに結果をすぐ確認できるようになってほしいですね。
おわりに
連載初回のインタビューとしてFJCTのIaaS基盤のプラットフォームを運用しているお二人にAnsibleに関連した取り組みを聞くことができました。
今後も様々なトピックでニフクラのサービス品質を維持向上するためにどのような取り組みが実施されているかをエンジニアさんの現場視点でお届けしていきますのでブログのチェックを是非よろしくお願いいたします。