インフラにおける改善の実際

本章では実在するサービスを題材に，インフラの改善で取り組んできたことを紹介します。

ヘテムル

執筆陣が関わっているpaperboy&co.（以下，ペパボ）のサービスは「ヘテムル」です。ロリポップ！ と並ぶレンタルサーバのラインナップで，大容量・高負荷に耐えうる上位のサービスとして提供しています。2005年リリース当初はサーバ数十台でしたが，それから規模や機能も増え，2013年5月現在は400台弱の規模にまで成長しました。執筆陣は4年前の2009年からヘテムルに携わっており，運用と機能改善を行っています。

インフラの技術的負債

インフラの技術的負債には次のものがあります。

• a．集中管理されていない設定情報によるサーバごとでの微妙な仕様差
• b．すばやい変更手段を持たないことによるサーバ全台展開の手間
• c．移り変わるハードウェア性能とそれを扱う運用の柔軟さがないことによるスペックアップの困難さ
• d．ルーチン化された作業が省力化されていないことによる運用のコスト
• e．無秩序な監視システム運用によるサービスヘルスチェック品質の劣化

これらはインフラに必ず付随する問題です。小規模のサービスでは大きな問題とはならなくとも，成長につれて大きく顕在化するリスクでもあります。

負債の返済

前述の問題は対処を怠ると，時を経るごとに新たなリスクが積み重なっていきます。問題を分割し，リスクが高い事柄から，さらなる負債を積み重ねないように対策していくことが大切です。

ヘテムルでも，これらの問題を解決していくことが運用改善の歴史でもありました。具体的には次の改善を行ってきています。

• a．提供しているサービスはすべてをバージョン管理下において管理する
• b．デプロイやサーバに対する変更ツールを整備し，属人化や煩雑さを排除する
• c．ベンチマークの指針と計測する手段を持ち，OSセットアップを省力化する
• d．システム構成管理ツールを用いてサーバ構築の省力化・仕様化を行う
• e．監視システム設定のレビューを行い，設定の一部は自動生成する

以降で時系列に沿って，それぞれどういう意図に基づきどのような施策を行ってきたかを紹介します。

すべてをバージョン管理下に

何をバージョン管理するのか

ソフトウェアと同様にインフラ（プラットフォームと言ったほうがよいかもしれません）のバージョン管理も，サービスの品質と運用精度向上には欠かせないものです。では，具体的に何をバージョン管理すればよいのでしょうか？ 一口で言ってしまえば「すべて」です。プラットフォームを構成するミドルウェアやその設定，スクリプトなどはそれぞれが複雑に依存し協調し合うことで，あるべき機能を提供するよう動作しています。そのため，そのどれもが欠けることなく，任意のバージョン下で整合性がとられていることが理想です。

優先度

とはいえ，すべてをバージョン管理下に置くというのは一朝一夕にできることではありません。すでに長年動いているシステムでは，1つのファイルをバージョン管理システムにコミットするのにもそれなりの手間と時間がかかるものです。そのため，ある程度優先度を設けて，順にコミットせざるを得ません。

ヘテムルではおおよそ次の順番で行いました。

• ① OSレイヤ，セキュリティ周り
• ② ミドルウェア設定
• ③ cron，運用スクリプト
• ④ 監視ソフトウェア設定

③④は，その内容によっては，ほかと同時に進めることもありましたが，①②はこの順番で行う必要がありました。より下のレイヤから仕様をfixしないことには，その上で動くものの適切な設定を考えることはできません。

セキュリティ周りについてはどうでしょうか。iptablesやhosts.{allow,deny}の設定などは，ものによってはミドルウェア側でも同様のポリシーを設定できます。しかし，先により影響範囲の広いOSレベルで，どのレベルまでセキュリティポリシーやアクセス制限を担保するのかを決めてしまったほうが，ミドルウェアのセキュアな設定を決定することが容易になります。また，意味の重複が避けられるため，そのあとのメンテナンス性も高くなります。