新卒インフラエンジニアが強みを活かして業務改善

はじめに
DMMのインフラ
実際に取り組んだ業務改善
終わりに
採用情報

はじめに

はじめまして、DMM.comラボインフラ部所属の菅野です。17新卒として入社し、ようやく1年が経ちました。学生時代は、研究ではデータ工学、趣味ではWeb開発をしていました。そのためインフラの経験はまだまだ浅いです。普段の業務では、主にサーバやロードバランサ（LB）の設定に加えて、学生時代に行っていた開発の知識を活かした業務改善をやっています。

今回は、実際にこの1年間で着手した業務改善についてお話したいと思います。

DMMのインフラ

本題に入る前に、DMMのインフラについて少しご説明させていただきます。

DMMは、多くのサービスと大量のトラフィックという大きな特徴があります。そのため、まだまだオンプレに重きを置いている環境となっています。しかし、パブリッククラウドを利用していないというわけではなく、AWSの利用も活発であると言えます。すぐにリリースしたい場合などはAWS、開発側が開発に専念したい場合はオンプレなど状況に応じた使い分けがなされています。

インフラ部では、いくつかにチームを分け、DMMのインフラ部分を支えています。

サーバインフラ担当
ネットワーク担当
配信担当
データセンタ担当
etc...

上記の中でも、私はサーバインフラを担当しています。

サーバインフラって何してる？

文字どおりサーバの払い出しはもちろんのこと、インシデント発生時の対応などが主な業務となります。

サーバの払い出しでは、サーバを用意し、ミドルウェアを入れ適切な設定を行い、開発の人たちに引き渡しを行います。基本的には、案件ごとにAnsible化しておいて構築することが多いです。また、設定変更の際にも設定だけを書き換えてAnsibleを再度流し込む形になります。

DMMでは、LBの設定もサーバインフラの担当になります。LBはサービスに紐付いているため、管理の問題や依頼の手間を省く目的でサーバインフラの担当となっています。

物理のLBを触ることができるのは、DMMの面白みの一つだと言えると思います。また最近では、仮想LBの導入も検討されています。

インフラ内での技術的トレンドは？

Ansible

Ansibleは有名な構成管理ツールです。

先ほども挙げたように、サーバの構築・設定の更新についてはAnsibleで行うことが普通になってきています。それだけでなく、下記のような検証も行っており、インフラ部内ではAnsibleは一般的なものとなっています。

qiita.com

StackStorm

StackStormは、イベントドリブンな自動化ツールとなります。OSSツールなIFTTTをイメージしていただくとわかりやすいかと思います。

実際の動作例としては、「GitHubにpushされたらコードのデプロイを行う」、「監視ツールがdownを検知したら自動的に再起動をかける」などの動作を行うことが可能です。

アーキテクチャにつきましては、以前のツチノコブログをご参照いただくといたしまして、ここではStackStormを使うことのメリットおよび実際に社内でどのように使われているのかをご紹介させていただきます。

tsuchinoko.dmmlabs.com

社内でのStackStormの利用

先ほど一例に挙げた「GitHubにpushされたらコードのデプロイを行う」などの処理は、Jenkinsでも実現可能なものとなっています。

では、StackStormを使う利点とはなんでしょう？それは下記にあると思われます。

APIでの操作が可能
GUI上だけでなく、コマンドでの操作も受け付けている
Rule（Jenkinsでいうところのジョブ）をYAML形式のテキストで記述可能
冗長化して使うことを前提としたシステム構成となっている

RuleをYAMLで記述可能なため、Gitで管理してレビューした上でデプロイできることから、Jenkinsのジョブと違い属人化を防ぐことが可能です。また、冗長化については公式サイトに構築方法が載っており、対障害性に優れた構成を組みやすいのは大きな利点になると思われます。

また、社内にはStackStormのコントリビュータがいるため、そういう点でも社内での利用の機運は高いと言えます。実際に社内ではStackStormを利用したVM構築システムが存在しており、コマンドを叩くだけで任意のスペックのVMが構築可能となっています。

実際に取り組んだ業務改善

ここからは本題として、実際に取り組んできた業務改善についてお話させていただきます。

そもそもなぜ新卒が業務の改善を？

最初に少し書いたとおり、学生時代は開発に重きを置いておりました。しかし、研究室に所属した際にインフラに触れる機会があり、DMMという大きなオンプレの基盤を持った会社で力をつけたいという思いからインフラ部に所属しております。

学生レベルだったものの開発側のエンジニアの視点や知識を持っていたので、それを活かして既存の環境を改善していく業務を任せていただいています。

Ansibleの再利用化の推進

私が入った時点ではすでにAnsibleが使われている状態だったため、新規案件についてはPlaybookを書き、gitで管理していく流れができていました。

しかし、一部のサーバではAnsibleを導入し始めた頃の遺産などが残っており、それらのサーバはPlaybookがデプロイ用のサーバに置いてあるだけでリモートリポジトリがないという問題点を抱えていました。

そこで、まず初めにすでにPlaybookが存在するものはすべてgitで管理を行い、リモートリポジトリに置いていくことを徹底していきました。

次に、よく使うroleや必須タスクなどはrole単位で切り分けを行い、ansible galaxyを利用してインストールできるようにすることで再利用性の向上に繋げました。roleの切り分けについてはまだまだ不十分な点があり、これからも様々なroleを追加していく予定となっています。

コンフィグファイルの自動デプロイ機構

再利用化の推進に伴い、Ansibleによるサーバの構成管理は正しく行われるようになりました。

しかし、一部の設定を変更しデプロイする場合はどうでしょう？そのためだけに毎回デプロイ用のサーバに入ってコマンドを叩くのは手間です。そもそも、設定ファイル程度ならPRを出し、レビューし、マージされた段階でデプロイしてほしいものです。そこで、開発では一般的な概念である継続的デリバリー（CD）をサーバの構成管理に適用することにしました。

サーバのCDを実現するにあたって、リモートリポジトリの変更検知については様々な方法が考えられますが、今回はStackStormを用いました。また、リモートリポジトリについてはBitBucketを利用しています。

しかし、上記の条件を満たしたシステムを構築するにあたって、考慮する必要のある項目が何点かありました。それは、StackStormを利用したリモートリポジトリの変更検知の方法、切り戻し方法、誤った設定が流れてしまう可能性、加えてどのようにSlackに通知するかについての4点です。

最初は、社内で利用しているStackStormにはBitBucketと連携するための仕組みが存在しませんでした。しかし、StackStormはpackというものをインストールすることでそのシステムに関するイベント検知やアクションを起こすことが可能になります。幸い、StackStormはBitBucketに対応していますので、今回はそのBitBucket packを利用しました。

切り戻し方法については、StackStormがBitBucketの変更履歴を常に確認しているので、revertコミットを入れることで対応可能であることを検証しました。

誤った設定が流れてしまう可能性については、まずは自動で実行される処理の影響範囲を狭めることで対策を行いました。具体的には、ファイルをデプロイするだけのroleを作り、他の影響が出ないようにしました。また、Ansibleの機能であるvalidateを用いることで誤った設定が流れ込まないように気をつけました。

Slackへの通知は、StackStormのSlack packとAction Chainを用いて実現しました。Slack packは、SlackのAPIを利用しているため、SlackAPIのドキュメント*1を見れば、あとはそれをyamlに起こすだけなので容易に利用が可能です。また、Action Chainについても公式サイト*2に利用方法が載っているので苦労なく利用可能でした。

実際に組み上がったシステムが下記になります

BitBucketに変更履歴が追加される
StackStormが変更履歴を検知
StackStormが検知したリポジトリに応じて、デプロイ用のサーバ上で適切なPlaybookを実行する
Ansibleの実行結果をSlackに通知する

f:id:sugano-kosuke:20180502190323p:plain

このシステムを構築することで、下記のようなメリットを得ることができました。

設定更新のためにサーバに入る必要がない
サーバの最新設定が常にリモートリポジトリにある
開発側への設定ファイルの共有が容易

また、このシステムの一番のメリットは、サーバインフラ担当でなくとも設定についてプルリクエストを飛ばすことが可能である点です。つまり、開発の人たちもサーバの設定に触れることが可能となり、ゆくゆくはインフラでは設定ファイルをレビューするだけで良くなるところまで持っていくことが目標です。

VM構築の自動化

元々、StackStorm上でコマンドを叩くだけでVMを構築するシステムは存在しました。しかし、セキュリティ的な問題やリソース管理の問題からそのシステムを利用可能なのはインフラ部の人のみとなっています。また、コマンドを叩くだけでVMが構築できるとはいえ、あくまで1台1コマンドになるので、複数台を作るのには何らかの工夫が必要となっていました。

そこで、VM構築のためのドメイン固有言語（DSL）を作成し、既存のVM構築システムのラッパーとして用意することで、インフラ部以外でもVM構築を可能にしました。

今回のシステムでは、前段としてJenkinsを利用しました。ツールとして何らかの言語でWebUIを作成するという手もあったのですが、そこまでの手間や今後のメンテナンス性を考えた際にJenkinsでコマンドを実行させるほうが効率が良いとの思いからです。また、DSLについてはYAMLを採用しました。理由としては、Ansibleで慣れている人が多いためです。また、jsonでは可読性の面で苦労がありそうだったためです。

こちらのシステムは下記の流れで動いています。

f:id:sugano-kosuke:20180514191143p:plain

このシステムのおかげで、YAMLを書きさえすればVMが立ち上がるようになり、今まで複数台のVMを構築する時にかけていた時間を省略可能になりました。加えて、開発の人たちにも実際に利用してもらい、インフラ部では開発の人たちが出したYAMLファイルのPRを確認するだけでVMが構築できるようになっています。