AirOne、IFTTT×Workflow、StackStormを活用した運用自動化　安価なインフラ提供とサポート品質向上のための仕組み

IFTTTとWorkflowについて

大山裕泰氏（以下、大山）：続いて、IFTTT× Workflowによる運用自動化の取り組みについて紹介します。その前に、おそらく聞きなじみがないと思うので、「IFTTT」と「Workflow」という言葉を整理します。

IFTTTはIf This Then Thatの頭文字です。IFTTTという名前のSaaSがあるので、混同するかもしれません（笑）。IFTTTは、あるシステムやサービスで発生したイベントを別のシステムやサービスに対する、イベントに変換する仕組みを表す一般名詞です。

IFTTTでは、起点となったあるシステムに対するイベントを“トリガー”と呼び、そのトリガーによって引き起こされた別のシステムに対するイベントないし処理を“アクション”と呼びます。

（スライドを指して）わかりやすいIFTTTの例として、このような組み合わせがあります。あるGitHubのリモートリポジトリの指定したブランチに更新が行われると、JenkinsでCI/CDが走ります。

（スライドを指して）Workflowは、ある一連の処理をコード化したもので、この図はサーバーの作成からクロージャニング、サービスインまでの一連の処理を行うWorkflowを表しています。Workflow自体は広く一般的に使われている言葉とほぼ同じ意味なので、イメージしやすいかと思います。

StackStormについて

冒頭で、IFTTT運用基盤による運用自動化の手段として「StackStorm」というソリューションを使っていると話しましたが、そちらについても簡単に紹介します。StackStormは、Linux FoundationのOSSプロジェクトであり、IFTTT機能を持ったWorkflowエンジンです。

StackStormは、Trigger、Sensor、Actionという3つの要素によってIFTTTを実現しています。

TriggerとSensorは、能動的もしくは受動的に外部システムからのイベントを検知する仕組みになっています。ただ、TriggerとSensorを通じてイベントを通知しただけでは、StackStormは何もしません。

イベントがどのTriggerから開かれて、どのActionをどのように実行するのかを定義したRuleが設定されて、StackStormは初めてあるシステムからイベントに対して別のシステムに対するActionを行います。

このようなTrigger、Sensor、Actionは、AWSやGitHubなど、さまざまなサードパーティ製のパッケージで管理されており、それらのパッケージをStackStormのパッケージ管理システムであるExchangeから自由に取得できます。これはChefのSupermarketやAnsibleのGalaxy、またDockerにおけるDocker Hubなどと同様です。

（スライドを指して）StackStormには、AWSなどのサードパーティ製のパッケージが170以上存在しており、運用上なんらかのサービスと連携する際、自身がSensor、Trigger、Actionを書かなくても、Exchangeから取得したパッケージを用いることでWorkflowを記述できます。StackStormの説明は以上です。

情報の棚卸しの自動化

ここからは、情報管理システムAirOneやIFTTT×Workflowエンジン、StackStormを活用して、どのようなインフラのサービスの提供やインフラの運用効率化を行ってきたのかについて、事例を紹介します。

まず取り組んだのが、情報の棚卸しの自動化です。先述のとおり、情報は常に変容するため、スライドの右側の情報管理システムAirOneで管理された情報が変化に追従しない場合、管理情報の信頼性もしくはその情報の精度が低下します。その場合、運用コストの増大という問題を引き起こすことが予想されます。

例えば、スライドの左側に示した仮想基盤。我々がVMwareのソリューションを使っていることはすでにいろいろな場所で話していますが、仮想基盤に管理されているVMの設定が更新されてもその変更が右側の情報管理システムに反映されない場合、情報管理システムには間違った情報が登録されることになります。

この場合、正しい運用が行われないだけでなく、運用者はその正しい情報を参照するために、1次情報にあたる必要があります。そのため、情報管理システムに確認したあと、vSphereにアクセスするという余計な作業工数が発生し、運用コストがかかります。

こうした事態を避けるため、これまでは常に一定間隔で情報の棚卸しを行ってきましたが、左側の仮装基盤の変更をStackStormが検知し、さらに情報管理システムとの情報の差分を検出して変更された情報の修正を行うといった情報の棚卸しが、自動的に行われるようにしました。

これによって従来人間が行っていた情報の棚卸し作業がなくなり、インフラのサービス品質や機能性を高めるような活動に、より多くの人的かつ時間的リソースを割くことができるようになりました。

AirOneのデプロイ

続いて、IaC（Infrastructure as Code）の実現になります。Ansibleなどを使ってIaCを実施することも多いかと思いますが、その場合、どのノードにデプロイするか。また、デプロイする際のパラメーターやデプロイ先のノードに設定する環境変数の情報などを、みなさんはどのように管理していますか。多くの場合、そうした情報もおそらくGitHubで管理していると思います。

AirOneはそのような論理・運用情報を管理するためのシステムなので、AirOneでサービスのインベントリ情報を管理し、StackStormでその情報を取得し、インベントリ情報とデプロイポートに従ってサービスのノードセットのクロージャリングおよびデプロイを行っています。

ただ、これらはIFTTTの例で示したようになGitHubとJenkinsで行っている内容とほぼ同じで、アプリケーションの開発を行っている現場でインフラを触っている人にとってはおなじみかと思います。

インフラの運用を自動化する際のあるある問題と回避策

続いて、インフラの運用を自動化する際のあるある問題とその回避策を紹介します。何らかの運用を行う際に、Workflowなどの手段を用いてコード化して自動化する場合、そのリソースの競合を避けるため、あるWorkflowを同時に実行させたくないケースが実際にありうると思います。どういうことか順に説明します。

スライドで示している図は、VMの作成とプロビジョニングを行うWorkflowになります。Workflow中で、例えばシリアルのIDやIPアドレスなど、重複してはいけないリソースの払い出し、またそれに続く処理の中で、例えばDNSへの登録やLBの設定の際に、それらのシステムでトランザクション制御が十分に行われていない場合。これらの設定をする際に、排他制御、つまりワーカーがある処理を実行していれば、ほかのワーカーが同じ処理を実行できないようにしなければなりません。

こうした排他制御をケアしないまま、ケアしなければならないWorkflowを複数のクライアントから同時に実行した場合、重複したシリアルIDやIPアドレスが同時に払い出されたり、DNSのレコードやLBの設定が別の処理によって上書きされたりといった、管理運用上の不具合を起こすことが予想されます。

こうした問題を回避するための最も安易な方法は、その当該処理を実行する前に、ほかの処理が同じ作業をしないようにすることです。例えば「これから誰々がこの機器を触るので、ほかの人は触らないでください」と宣言してオペレーションを実行し、運用でカバーする方法があります。

当然、これらの方法はスケールせず、イベントドリブンな運用はおろか、人による運用の域から出ないので難しくて、運用自動化がうやむやになりがちです。

しかしStackStormを用いたWorkflowを用いれば、Workflow中の特定のジョブで排他制御が必要な場合にもStackStorm Policiesという仕組みが適切に行えます。

その仕組みについて簡単に紹介します。（スライドを指して）StackStormに#Aから#Cの3つのWorkflow（実行するワーカー）があるとします。ここに、先のスライド1から4のActionが記述されたWorkflowを実行すると、StackStormは当該Workflowをどのワーカーで実行するかのスケジューリングを行います。その結果、ワーカーBでWorkflowが実行されたとします。

すると、1つ目のActionから順番に実行されることになります。この場合は同時に1つのWorkflowだけが実行されるので特に問題ありません。

あらかじめこの1つ目と3つ目のActionを同時に実行してはいけないとStackStorm Policiesで定義しておけば、たとえ3つのワーカーから同時にWorkflowを実行するリクエストが来たとしても、実行時にStackStormが1と3のActionをほかのワーカーで同時に実行しないよう、タスクをスケジューリングしてくれます。

このように、StackStormを使うことで、これまで排他制御の問題で自動化できなかった運用であっても、Action自体に排他制御の仕組みを組み込まなくても、自動化が可能になります。

共有のインフラリソースの調停

最後に、これらの仕組みを用いてインフラ部が管理・運用する共有リソースを調停するサービスについて紹介します。我々インフラ部は、ネットワークをはじめ、仮想基盤、LB、DNSなど、すべての事業部に共通するインフラを管理・開発・運用しています。

すべての事業部に共通するインフラリソースを、それぞれの事業部に提供しています。逆に言えば、インフラ部はすべての事業部が利用する共有リソースを、事業部からのリクエストに応じて調停、つまり事業部に変わって運用・実施しています。これは、ほかの事業部の占有リソースを害するリスクを低減するための措置になります。

しかし、想像すればわかるとおり、インフラ部が事業のボトルネックになる可能性があります。これにおける2つの問題点の1つは、事業部からVMシャットダウンさせるような、非常に簡単な要求ですら人手による作業時間を要すること。もう1つは、インフラ部の運用コストが増大することです。オンプレのサービス品質や機能性を高めるための施策へのリソースが投入できない問題が、こういったボトルネックによって行われます。