エムスリーテックブログスマートフォン用の表示で見るエムスリーテックブログエムスリー(m3)のエンジニア・開発メンバーによる技術ブログです2018-08-08デプロイの度に障害が起きるシステムを安全にした話SRE鉄道では個人の注意力だけでなくシステムにより安全を確保している。写真は「タブレット閉塞式」のタブレットを交換する様子。1つの区間にはタブレットを持った列車しか進入できないため、衝突事故を防ぐことができる。ウィキメディア・コモンズより)こんにちは、エムスリーでソフトウェアエンジニアとして働いている小本です。私は基盤開発チームという、エムスリーの複数のサービスにまたがって使われるシステムを開発・運用するチームに所属しています。基盤開発チームが担当するシステムの1つに、会員向けメルマガの配信システム「メールコンシェルジュ」があります1。エムスリーはメールコンシェルジュで1日数十万通のメルマガを配信しており、機械学習でメルマガを最適化する施策2などもメールコンシェルジュの存在が前提になっています。このようにエムスリーにとって重要なシステムなのですが、メールコンシェルジュは数年前まで運用、特にデプロイに問題を抱えていました。デプロイ時のミスによる配信障害が頻繁に発生し新人がデプロイすると必ず障害を起きるという状況だったのです。1回デプロイするのに30分かかり、デプロイ中はメルマガの配信ができませんでした。「怖すぎるデプロイ」の辛さ言うまでもなく、障害が発生している間はメルマガを配信できません。「今配信すること」が重要なニュース系メルマガは「障害が解消してから送り直す」ことができず、大きな機会損失に繋がります。障害対応に時間を取られれば、そのぶん開発に割ける時間が少なくなります。それだけではなく、エンジニアにデプロイに対する恐怖心が刷り込まれていました。デプロイしたくないので管理画面の表示崩れのような簡単な不具合修正すらためらったり、複数の変更を一つにまとめてリリースしたりしていました。話なのに3、エムスリーでは1回30分もかかるなんておかしいよ!!」と思いました。デプロイはそれ自体は価値を産まない作業ですから、「障害の恐れがある危険な作業」ではなく「誰でもできる簡単なルーチンワーク」であるべきです。基盤開発チームでは、メールコンシェルジュ本体の開発のかたわら、デプロイの改善も行なっていきました。デプロイ手順書の作成まず、ともあれ新人がデプロイすると必ず障害が起きるという状況を何とかすることにしました。masterunicornを再起動テスト配信する例えば単に「テスト配信する」と書かれても手順書としては役立ちません。配信には複数のオプションがあり、ベテランはともかく新人には、どんな設定でテスト配信すればいいか分からないからです。新人でも間違えることが無いよう、全ての設定項目を指定し、コピペするだけでデプロイできるような手順書に書き換えました。NO」これで、本番環境へのデプロイは(一応)誰でも安全にできるようになりました。次に、デプロイ作業の自動化をしたかったのですが、デプロイ用のスクリプトをテストできないという問題がありました。本番環境の他に開発環境があったのですが、あくまで開発用であるため、本番との差異がありました。本番はサーバー4台構成なのに開発環境は1台でした(かつてはサーバーのコストが高かったため、止むを得ない部分もありますが)。エイヤッ!と、本番環境で実行することもできます。ステージング環境を用意しました。実際に本番同様のステージング環境を作ってみると、開発の際にも本番同等の環境の方が便利だと分かりました。今では、ステージング環境を3つに増やし、かつての開発環境は廃止しています。手順書の内容を実行するシェルスクリプトを作りました4。コマンドを1回実行するだけで、各サーバーにSSH、最新コードのチェックアウト、インストール、サーバー再起動、簡単な動作検証、までが完了します。これによる心理的効果は莫大でした。」で出来るようになったんですから。手順書やスクリプトを作り目に見える形にしたことで、デプロイ手順について議論できるようになりました(今までは、議論しようにもできなかった)。時間短縮メルマガを配信できない時間を減らすため、スクリプトを改良していきました。Rubyライブラリのインストールだったため、以下のような改善をしました。メルマガが配信できない時間)を短くすることができました。やめる自動化によりRubyのコードのデプロイは安全・簡単になりましたが、たまに行う作業の中には危険なものが残っていました。一つは、メルマガを追加したりする時などにDBの内容を変更する作業です。スニペットからSQLをコピペして実行」という原始的な方法で行なっていました。そのせいで事故も多く、当時「DB変更は本質的に危険な作業なんだ」と言われていました。DB変更も「よくある作業」なのですから、できるようにするべきでしょう。