(株)うるる に2015/06初に入社してから2018/08末で、インフラのカイゼンに一区切りついたのでまとめます。

10年モノというのは うるるで運営しているサービスが最長で10年 ほど経ってスゴイことになってました。

3年がかりなのは、インフラ大好きエンジニアが社内に少なくて、私の独り相撲で時間かかってしまいました。

カイゼンの内訳はざっくりこんな。

構成要素	2015/06初	2018/08末
CI	jenkins	CircleCI
監視と通知	zabbix(ログインできない)	Datadog & CloudWatchの混成
MySQLサーバー	MySQL on EC2	RDS (MultiAZ)
メール送信	EC2から直接送信とSESの混成	Mailgunで固定IP
crontab	EC2にSSHしてcrontab -e	wheneverでgithub管理
crontabで動かしてるシェルスクリプト	EC2にSSHしてvi。SCPで配布	github管理
ログファイル	EC2のEBSにひたすら蓄積	CloudWatch Logs
EC2の中身	viして同ロールのEC2にSCPで配布	Ansibleでgithub管理
Solrサーバー	Master/Slaveが1セット	Blue/Green構成
AWSアカウント	1垢に複数サービスが雑居	1垢1サービス & VPCでprod/stg/devに分割
ネットワーク	EC2 Classic	VPC

CI

いちおうJenkinsが立ってました。失敗して赤くなってるジョブが大半で、かといって誰が治すわけでもなく、よくわからないけど失敗したり成功したり、とにかく不安定でした。

CloudWatchのメトリクスで眺めて、EBSのIOPSクレジットの枯渇から激遅になって、Jenkinsジョブのタイムアウト設定で失敗になる、まで明らかにしました。その時の対処は、IOPSクレジット上限サイズの1TBのSSDのEBSを付けることと、同時並行で動けるJenkinsジョブ数に上限を設けることで、落ち着くようになりました。

とはいえ「Jenkinsおじさん」問題があるので、CIをどうにか民主化する必要があります。SaaSから検討して、TravisCIとCircleCIが最終候補になって、トラブルシュートをSSHでできるのを決め手に、CircleCIを導入しました。

8月末にCircleCI1.0が死んだときの2.0への移行作業はわりとキツかった。

監視と通知

計測、管理、改善の原則にしたがって、現状を可視化できるようにしたかったので。

zabbixが稼働して通知も来ていたものの、ログインできる人がいない。わけがわからないですね。社内に声かけて、EC2のSSH鍵とzabbixの認証に使ってたOpenLDAPのSSH鍵を入手して、OpenLDAPの管理者アカウントのパスワードを変更して、ようやくzabbixにログインできました。ついでにログインできる人が少ないので、共有アカウントを発行して、OneLoginに接続して、エンジニアなら誰でも見れるようにしました。

zabbixに入ってみると、監視項目がザル。EC2インスタンスは、エラーログの監視、ロードアベレージの監視、ストレージ空きの監視、程度。ダッシュボードも無い。

• 障害発生をユーザーからカスタマーサポートチームへの問い合わせで気づく、
• 営業メンバーがお客様のオフィスでデモしてる最中に白画面(HTTP 5xx)で気づく、
• 朝、出社するとオフィスがざわついてて気づく

こんな状況だったので、zabbixを超いい感じにしても駄目な未来がみえました。もっと簡単に管理できるもの、当時はSaaS型が流行りはじめたころで、NewRelicとかMackerelとかのSaaS型から、最終的にDatadogを選びました。

MySQLサーバー

サービス本体のMySQLは入社時点でRDSになっていたのですが、社員がちゃんと関与していなかったサブシステムのMySQLがやばいことになっていました。AMIを取っているものの、mysqldumpでバックアップが失敗してる。このEC2が消滅したらどのくらい困るのかアプリのエンジニアに聞くと、いやそれは大いに困る、サービスのデータが数日抜けてお客様からクレームがくる程度に困ると。怪談です。

幸いにしてcron起動のバッチジョブのためだけのMySQLだったので、cronを止めて、mysqldumpして、予め立てておいたRDSに投入するだけでした。

メール送信

AWS SESは、料金の安さやセットアップの簡単さなどから、まあ普通に使うサービスです。しかし、SESからユーザーまでのログを取れない、そのくせバウンスレードでいきなり止められたりする。トラブルに弱い。

SESから受け取ってくれないお客様もいて、その方々のために、EC2にpostfix立てて送信もしてました。バッチサーバーもWebサーバもメール送信するので、SPFレコードに全台のIPアドレスが記載してあるという。SPFレコードに記載できる文字数に上限があって、サービスのスケールの上限でした。テレビ対応で増強したときは諦めてました。

このあたりの運用改善を主眼に、Mailgunに移行しました。結果、

• SPFレコードはMailgunのみになったので、スケールの上限が外れた
• Mailgunの過去2週間の送信ログで、カスタマーサポートチームがお客様と会話できるようになった

crontabと、crontabで動かしてるシェルスクリプト

6割くらいのシェルスクリプトはgithub管理されていたのですが、4割くらいはEC2サーバーに転がっていました。そのEC2サーバーでオペミスこいてシェルスクリプが消滅したら、どうリカバリするんだと。github管理に改めました。

crontabの6割くらいは、リリース時にwheneverで投入していましたが、残りはcrontab -eしていたようです。オペミス消滅どうリカバリの流れで、github管理に改めました。

ログファイル

EC2のEBSにひたすら蓄積していました。EBS、高価いんですよね。しかもトラブルがおきるとSSHしてシェル芸で調査するという。1台だけならともかく、複数台編成のウェブサーバーだと、もう1台でサンプリングで調べるみたいな状況でした。

ログを保管してくれるSaaSはいくつか出始めたころでしたが、安いのと、とりあえず保管できればいいしで、CloudWatchLogsを選択しました。

EC2の中身

crontabの管理状況や、zabbix設定がそんなだったので、もはや何も驚きません。EC2インスタンスの中身はブラックボックス。秘伝のタレが継ぎ足され続けてて、構築手順はAMIから立てるしかない状況でした。

MySQLの追い出し、crontabのコード化、シェルスクリプトのgithub管理、の流れで、Ansibleで管理することにしました。PuppetやChefがまあまあ辛くて、Ansibleならsshできれば動くしいいんじゃね？みたいに流行りはじめた頃でした。

• ps, chkconfig, netstatなどで稼働してるデーモンを調べて、
• /etcのどこかに散らかってる設定ファイルをかき集めて、
• ansible経由でEC2インスタンスに設置できるようにして、

というリバースエンジニアリングでansible化を進めていきました。最終的に、Amazon提供のAMIから立てたEC2インスタンスを新規作成して、このansibleコードを使ってセットアップして、アプリをデプロイして、動作に差異がないことをもって、ブラックボックスが解消できました。

Solrサーバー

Solrなので、定義変更するとインデックス作り直しになるのですが、クラスタがひとつだけだと果てしない困難があります。クラスタがふたつあればいいじゃん、いわゆるblue/green deploymentだぜ、からのちょろちょろっと手順を整備して、capistranoとansibleも調整して、で実現しました。

AWSアカウント & VPC

ここまでで、EC2内の諸々がgithub管理されて、新規作成からansible適用とアプリコードデプロイで完全動作することが保証できました。

しかしEC2が立っているのは、EC2 Classicネットワークです。残念です。これがために、ALB, WAFが使えず、EC2のt2やc4,m4などの世代が利用できません。さらに、AWSアカウントはひとつで、全サービスがごたまぜになってます。いろいろと奇跡的です。

AWSアカウント移設をしつつ、移設先はVPCにする、という引っ越しをしました。そのときの予備調査が https://qiita.com/sasasin/items/17135d5c5465fc53d385 だったりします。

一度に全要素を引っ越すのは、サービスのダウンタイムと私の体力を考えると無理だったので、

• RDS移設
  • ElasticIPで許可して、アカウント跨ぎで接続できるようにした
• Solr移設
  • blue/greenのスタンバイ側を引越先で稼働、blue/greenスイッチ
• ウェブサーバー移設
• バッチサーバー移設
• S3移設

というように段階を踏んで実施しました。

総括

いやもう本当よくやったよ私。自画自賛。