事業部向き合いの業務負荷軽減の取り組み
ここで述べる内容は、第1回のDevOpsで紹介した例と同じ背景ですが、サービス運用者の立場から見た課題とStackStormで何を解決しようとしているかについて紹介します。
DMM.comラボのインフラ担当部署（以下「インフラ」）では、DMM.comがお客さまに提供するサービスを運営する事業部やアプリケーション開発を行う部署に対して、共通のインフラサービスを提供しています。
インフラは対象システム、およびオペレーションの内容に応じたワークフロー（定型化された依頼を利用者がどのように申請し、申請された依頼に対してどのようにインフラの担当者がオペレーションを実施、報告するかを規定した一連の作業マニュアル）を定義します。インフラ利用者はこれに沿った形で依頼内容を所定のフォームに記載し、インフラに対して依頼を出します。依頼を受け取ったインフラは、出された依頼の内容に応じて担当者が必要なオペレーションを行います。
このように利用者が依頼内容を記述し、インフラの担当者がそれを読みくだす運用は、非定型化された依頼（「xxxの設計をしてほしい」「yyyの問題の調査をしてほしい」など）を対応する場合には効果的である一方、機械的に処理可能な定型的な内容の依頼（「以下のサーバをxx台構築（設定変更・削除）してほしい」など）を対応する場合には運用コストが高くつくと思われます。
DMM.comラボのインフラでも、利用者からの依頼に対応するためのワークフローを定義していますが、チャットなどの非定型的なコミュニケーションパスでインフラ運用者に対して直接、定型作業の依頼を受け、インフラの運用担当者が忙殺されている様子を時々目にします。
またオペレーションに人間が介在するため、事業が拡大（事業部のスケールアップ・スケールアウト）した場合、インフラの人員規模も拡大を余儀なくされます。これにより、インフラの管理・運用コストがさらに増大します。
こうした問題に対する一般的な解決方法として、インフラを利用するアプリケーション開発者がプログラマブルに操作可能なインフラサービスを利用して、開発者が直接インフラを運用するといった方法があります。
これに対してDMM.comラボのインフラでもインフラのサービス化に加え、さまざまなシステムのイベントを監視し、定型化されたオペレーションをコード化することで、定型作業を自動化する取り組みを行っています。
具体的には、構成管理システムやソースコード管理システムのリポジトリの更新などのイベントを検知し、コード化したオペレーションを実行することで、インフラ担当者の定型作業を自動化しようとしています。
これにより、インフラは個々のシステム自体の管理・運用に専念できるようになるため、より高機能なインフラサービスの提供が可能になると見込んでいます。
また、カタログ化されたオペレーションをAPIとして提供することで、全てのアプリケーション開発者がプログラマブルにシステムへのオペレーションが行えるようになります。これにより、要求を出してからオペレーションが完了するまでのリードタイムが短縮し、利用者がより効率的にインフラを利用できるようになると見込んでいます。
さらに、オペレーションに人間が介在しないため、事業がスケールしても、オペレーションのための人員増加は必要なくなります。この場合、StackStorm自体のスケーラビリティが要求されますが、StackStormはスケーラブルなアーキテクチャとなっており、こうした利用者の規模の増減に対しても柔軟に対応できると見込んでいます。
おわりに
ここまで、DMM.comラボのシステムの運用における課題の一部について、どのように解決しようとしているかをご紹介しました。
現在これらの課題解決に取り組んでいる最中のために、全てにおいて期待通りの結果が得られるかは本稿執筆時点（2017年8月）ではわかりません。もし期待した結果が得られなかった場合には、その詳細（どのような要因が何に対して、どのように作用したためにどのようになったかについて）をまたの機会にご紹介できたらと思います。
