2018年4月、データセンター完全クローズ
一休は、今年の4月にデータセンターを完全にクローズしました。現在、すべてのサービスをAWSを使って提供しています。
この過程で各種運用ツールやビルド/デプロイのパイプラインなどをすべて外部サービスを使うように変更しました。
これによって、インフラエンジニアやサービス運用担当者の役割や業務が大きく変わりました。本稿では、その背景を簡単に紹介したいと思います。
ざっくり言えば、
- 物理サーバのセットアップ&データセンターへの搬入のような仕事はなくなった。
- アプライアンスの保守契約、パッチ適用、運用ツールのバックアップのような仕事もなくなった。
- 各種メトリクスを見ながら、Infrastructure as Codeでクラウドリソースの管理や調整をする仕事がメインになった。
- 必要に応じて、プロダクトのソースコードに踏み込んで必要な改修を行い、サービスの安定化を支援する仕事も増えている。
結果として、SREとしての役割が求められるようになっています。
クラウド移行
一休のクラウド移行は、2016年末にキックオフ、2017年夏のアプリケーションサーバの移行を経て、2018年2月のデータベースの移行で、完全に完了しました。
概要は、過去の@shibayanと
id:ninjinkunの記事でも紹介しています。
これに伴って、以下のようなツールやミドルウェアも外部サービスに移行しました。
- ソースコード管理はGitHub Enterprise から GitHub.comへ
- CI/CDはJenkins + ファイル同期ツールからAppVeyor & CircleCIへ
- リバースプロキシはBIG-IPからFastlyへ
- メールサーバはアプライアンス製品からSendGridへ
- etc
それぞれに、
- 移行の動機
- 移行のタイミングで一緒に改善できたこと
- 移行によってなくなった作業
があります。
GitHub Enterprise(GHE) から GitHub.comへ
- [移行の動機] GHEを使い続ける必然性がない。
- [一緒に改善] 不要ファイルを削除してリポジトリのサイズダウン。
- [なくなった作業] GHEのバックアップとバージョンアップ。
もともと、社内にGitHub Enterprise(GHE)を立て、ソースコードを管理していました。しかし、社内環境で自前で管理する必然性がありませんでした。
そこで、運用環境をクラウドに移行するのをきっかけにして、GitHub.comへコードを移行しました。
このとき、宿泊予約サービスのソースコードリポジトリに大量に残っていた不要な画像をGitHubへの移行対象外にしました。これによってリポジトリが小さくなり、CI/CDの速度が向上し、開発時のリポジトリ操作の快適になりました。
そして、GHEのバックアップやバージョンアップという作業がなくなりました。
※ 画像の改善については、以下の
id:kentana20のスライドに詳しいです。
Jenkins + ファイル同期ツールからAppVeyor & CircleCIへ
- [移行の動機] 複雑になってしまったJenkinsをクラウドに持っていく必然性がなかった。
- [一緒に改善] ビルドパイプラインの安定化 &リリース回数アップ。
- [なくなった作業] Jenkinsのジョブのメンテナンス、不安定なファイル同期ソフトの管理。
CI/CDは社内に立てたJenkinsが担っていました。自前でブルーグリーンデプロイを実現するために複雑なジョブを組んだ結果、メンテナンスしにくくなっていました。またJenkins はバージョン1系を使っていたのでジョブの定義をGitHubで管理できていませんでした。
そして大きな問題だったのがビルド結果を配布するのに使っていたファイル同期ツールです。このツール、有償の製品だったのですが、動作が安定しない。。。
結果、途中でデプロイが失敗して手動でリカバリする、という辛い作業を繰り返していました。
運用環境をクラウドに移行するに伴い、このデプロイの仕組みをそのまま持っていく必然性はありませんでした。
また、アプリケーションはAWS Elastic Beanstalk(EB)を使うことに決まっていたため、デプロイは完全にEBが提供仕組みに任せることができました。
あとは、ビルドをどうやるか、ですが、AppVeyorとCircleCIで実現することにしました。CircleCIだけではWindowsプラットフォームで動作するアプリケーションのビルドに対応できないため、AppVeyorも併用しています。
AppVeyorもCircleCIもymlファイルで制御できるので、アプリケーションのリポジトリで一緒に管理することでメンテナンスしやすくなりました。
この移行によって複雑なJenkinsジョブや不安定なファイル同期ソフトのメンテナンスをする必要がなくなり、CI/CDパイプライン自体が大幅に安定しました。
その結果、リリースに手がかからなくなったため、本番リリースの回数を増やすことができました。
BIG-IPからFastlyへ
- [移行の動機] クラウドに持っていくのは高コスト。
- [一緒に改善] FastlyのCDN積極活用によるサイトのUX改善と安定化。
- [なくなった作業] アプライアンスの監視、メンテナンスや保守契約更新。
データセンターでは、ロードバランサ/リバースプロキシとしてBIG-IPを使っていました。
BIG-IPにはiRuleと呼ばれる独自のリライト、ルーティングの機構が搭載されており、一休でもこれを使っていましたが、管理が大変でした。
また、BIG-IPをクラウドに持っていくのも、移行後の運用コストを考えると難しいと判断しました。
そこで、クラウド移行に伴い、BIG-IPの代わりにFastlyを使うことにました。
FastlyをマネージドなVarnishが搭載されたリバースプロキシととらえ、VCLファイルをGitHubで管理し、TerraformとCircleCIでCI/CDを構築しました。結果、インフラエンジニアでなくても、ルーティングのルールを修正できるようになりました。変更に対する心理的な負担も大幅に軽減されました。
また、負荷対策やUXの改善のためにCDNとしての機能も積極的に活用しています。
さらに、にFastlyの進化の恩恵を自動的に受けられるのも大きいです。例えば、ほとんど何もせずにHTTP/2を導入することができました。
アプライアンス製品のメールサーバからSendGridへ
- [移行の動機] クラウドにアプライアンスを持って行くわけにいかない。
- [一緒に改善] メール関連の処理をリファクタリングして合理的に。メルマガ配信も簡単にSendGridに移行。
- [なくなった作業] アプライアンスの監視、メンテナンスや保守契約更新。
データセンターではアプライアンス製品のSMTPサーバを使っていましたが、これもクラウドに持っていけません。そこですべてのメールをSendGridを使って送信するようにしました。日本の代理店である構造計画研究所様にもしっかりとサポートしていただきました。
移行の詳細は、過去の@shibayanの記事や、@minato128のスライドが詳しいです。
https://speakerdeck.com/minato128/ikyu-mail-platform
移行に伴い、積極的にリファクタリングしました。
例えば、メール送信の必要性を棚卸しして、不要なメールは廃止しました。また、開発者向けのエラー通知メールなどメールである必要のないものはSlackへの通知に切り替えました。
この移行でアプライアンスの保守更新やパッチ適用などの各種メンテナンス作業から解放されました。
また、別の外部サービスで実現していたマーケティングのメール配信も比較的簡単にSendGridに移行できました。これによってメールマガジンの配信コストが大幅に削減できました。
仕事が減った(^^) じゃあ何する？
ほかにも、アプリケーションログの管理や本番データベースの定期運用などにも同様の変化が起きました。この結果、インフラエンジニアの管理作業が大幅に削減できました。
では、今はどんなことをしているかというと、、、
Infrastructure as Codeでクラウドリソースの管理
もちろん、クラウドに移行したからといって、キャパシティプランニングや配置設計のような仕事がなくなるわけではありません。
むしろ、リソースを柔軟かつ素早く確保できるというクラウドのメリットを積極的に活用してサービスの安定化に貢献する必要があります。
一休ではクラウドリソースの管理をTerraformを使ってAWSのリソースを管理しています。
モニタリングはDataDogを使っています。DataDogのメトリクスを見ながら、リソースの消費具合の推移をにらみつつ、必要な調整を行うのは重要な仕事の一つです。
また、新規サービス構築ではプロダクトを開発しているエンジニアと協力して、Terraformを使って必要なクラウドインフラをセットアップし、モニタリングの設定を行います。Terraform自体のバージョンアップやメンテナンスも重要な仕事です。
プロダクトのソースコードに踏み込んで必要な改修を行う。
プロダクトのコードを修正する機会も増えています。特に、サービスの安定化に貢献できるような修正をしています。
例えば、キャッシュの導入や高負荷なSQLの分割 & 非同期化などです。
つまり、サービスの安定化がミッションになっています。
というわけで、 インフラエンジニア改めSREになりました。 一休ではインフラエンジニア改めSREとして活躍してくれる仲間を募集しています。
当社については以下の紹介記事をご覧ください。
この記事の筆者について
- システム本部CTO室所属の 徳武 です。
- サービスの技術基盤の開発運用、宿泊サービスの開発支援を行なっています。
