幼いころは外交官を目指していた意識高い系インフラエンジニアの渡邉です。

5月にラクスルに入社し、最初の大きなミッションであったAWSへの移行を9月頭に実施しました。その際に得た知見や工夫した・改善した部分を、同じようにレガシーシステムと戦っている皆様に共有すべくMeetupを開催させて頂きました。

そこでの発表内容をインフラ編・アプリ編と二回に渡りご紹介させていただきます。

なぜ移行したのか

スタートアップあるあるですが、「インフラ」というと専任エンジニアは不在でアプリケーションサイドのエンジニアだったり、CTOだったりが片手間に担当していることが多いと思います。
PVが少ないうちはいいのですが、幸いにも注目が集まりPVが増えてくると色々と問題が浮上してきます。

ラクスルも例外ではなく、SPoFが放置されていたり、監視が漏れていたり、disk fullの足音が毎朝聞こえてきたりともう場当たり的な対応ではにっちもさっちもいかない状況になってきていました。
これからさらに事業を拡大させていきたいというところで土台がぐらついていては、そのスピードを阻害することになる！ということでインフラ専任として私が入社する時点から、抜本的にインフラを作り直すことにしました。

スケジュール

• 4月
  • パブリッククラウド費用比較
  • 移行意思決定
• 5月
  • 移行対象確認、全体設計
  • 現行環境調査
  • 監視や運用周りの環境構築
• 6月
  • 移行先本番環境構築
  • deploy改修
  • jenkinsを利用したchatops整備
• 7月
  • テストケース作成
  • QA環境構築
  • 外部接続ポイント洗い出し
• 8月
  • ひたすらにテスト
  • 開発環境整備
• 9月
  • 移行作業

上記の通り、実質5ヶ月ちょっとで要件定義から移行までをやりきりました。
当初は3ヶ月を見込んでいたのですが、もうスタートアップとは言い難いほど醸成されてしまったシステムは中途半端なテストでは移行できないという判断の元、テスト期間を延ばしたことが理由で、ここに後悔はありません。

ビジネスモデル上、パートナー様など外部接続ポイントが多岐に渡り、ここの洗い出しとテストに特に苦心しました。

何が良くなったのか

コストが下がった

ランニングで約30%ほど費用削減ができました。
主にstorage周りが大きく削減でき、さらにaws accountをサービス単位で分割することで何にいくらかかっているのかを明確化しました。

監視・運用が強化された

監視をzabbixに集約、自動化したことで監視漏れが起きなくなりました。
Provisioningにchefを採用し、サーバ構成の冪等性が担保されるようになりました。
合わせて、route53やs3 bucket policy, IAMなどのリソース管理をrubyスクリプトに落とし込み、コードでの管理を徹底しています。
また用途管理のためのホスト情報をDBに格納し、さらにCustom TagをEC2に付与することで何がどこで動いているのか、がわかりやすくなりました。

セキュリティレベルが上がった

アクセスログに出力する情報を拡充し、状況を追いやすくしました。
ssh,sudo認証をopenldapに切り替え、アクセス制御を可視化、効率化しました。
ACMでの証明書発行を行い、全https化を実現しました。

パフォーマンス、可用性が向上した

主にデータベースのスループット上昇に起因するところが大きいですが、webのresponse timeが約1/2に改善されました。
Auroraの採用により、failoverが爆速になりレプリ遅延もほとんど考慮しなくてよくなりました。

まとめ

振り返りとしては、「本番でしかテストができない」部分は移行後に確実に問題が起きる、ということに尽きます。
インフラ面でいえば外部接続部分とメール送受信周りがそれにあたり、移行後かなりトラブルシュートに時間を要しました。
利用できるManaged Serviceを積極的に採用することで、面倒を見なくてはいけないものを極力減らすことにFocusしたため、移行後の運用工数は非常に減ったなと感じています。

とはいえまだまだ効率化、堅牢化する余地が多分に残されていますので、今後も最新技術動向を見定めつつ環境のブラッシュアップは行っていきます。

次回以降のブログで改善点についてもう少しテッキーな部分に踏み込んでのご紹介ができればと考えています。

次回予告

次週はCTO泉によるアプリ編のご紹介になります。
移行に対するアプリケーションサイドの心構えや、テストについてが語られる予定ですので、お楽しみに！！