はじめに

こんにちは。サービス開発部新卒２年目のIです。

先日2020年5月21日夜、Google Cloud Japan様主催のウェビナーに弊社の辻が登壇しました。紹介されたインフラのリプレイス事例は、私自身も参画した事例ですので、当日は私もウェビナーに生で参加しました。

今日は、そのときお話させていただいた内容を元に、弊社サービス開発部がどんな課題を持ち、どのように解決したのか、テクニカルな面も混じえながらご紹介できたらと思います。

■解決したかった課題

世の中には多くの課題があり、それらの課題を解決する手段も多様です。私たちサービス開発部メンバは技術者であり、それらの課題を解決するために、課題を分析し、最適な技術を選定します。一度問題が解決できても、時間が経つと、また新たな課題が出てきますし、新しい技術がそれらの課題解決を加速させてくれることもあります。課題解決には終わりがありません。

今回行ったインフラのリプレイス前に、ZUUのサービス開発部が抱えていた課題は大きく２つあります。

１つは、インフラの運用コストです。インフラのパフォーマンスは、ピークアクセスに耐えるように設計していました。そのため、アクセス数が少ない深夜などには、過大なものになります。事業の成長に伴い、アクセス数は毎月増加していましたが、ピークアクセス数はそれ以上のペースで増えてきていたため、より高負荷に耐えられるようにしていくためにサーバを増強したため、コストが大幅に増大していっていました。そこをオートスケールさせることで、インフラの運用コストを軽減させたいと考えていました。

もう１つは、インフラの構成です。近年の技術トレンドであるインフラをコードで自動化していく思想である、Infrastructe as code を目指していたものの、まだまだ課題が残っていました。例えば、暗号化情報の一部は手動管理になっていました。また、増えていくテナント（弊社CMS提供先顧客）毎に、インフラを構築していたため、すべてのインフラリソースがテナント数に比例して増えていました。運用する中で、セキュリティアップデートやミドルウェアのバージョンアップなども必要になりますが、それらの作業も各テナント毎に作業が発生していました。リソースの共通化を進めることで、それらの作業と運用コストを削減することが、事業拡大に向けて求められていました。

■解決するための技術選定

目の前の課題は整理できました。その課題を解決するために私たちは最善の方法を採るため、新しい技術の選定を行いました。

弊社はGCP（Google Cloud Platform）を使用しており、GCPには新しい技術を用いたサービスが続々と追加されています。それらのサービスを導入することで課題を解決する方法を検討しました。その中で注目したのがGKE（Google Kubernetes Engine）でした。GKEは近年利用が増えているKubernetesに対応したGoogleのサービスで、その長所は、オートスケール設定が容易なことでした。弊社の環境をGKEに移行すると、簡易なパラメータ設定により、アクセス数が少ない時間帯にはインフラ性能を下げることで、インフラ費用を抑えることが見込めました。

そして、そのGKEに加え、その他GCPの新しいサービスを導入することで、Infrastructure as Codeの思想に則り、環境構築の自動化や構成を簡易にすることができることもわかりました。直面している課題は解決できると私たちは確信しました。

■インフラ環境とオートスケールの検証

技術選定が終わったので、次は動作検証です。これまで構築してきたシステムは多機能になっているため、検証は広範囲に及びます。実作業がたくさんあり、多くのメンバーを巻き込んでいかなければなりません。また、新たな技術を導入するため、その調査・習得にも時間が必要です。そのために、それらをタスク化し、細分化し、計画をたてました。

最初の大きなステップは、インフラ環境の検証でした。旧インフラはVMインスタンス上にバイナリをビルドし、それを本番サーバにrsyncでリリースする仕組みでしたが、GKEを採用した新方式では、Dockerイメージをビルドし、そのDockerイメージをリリースする仕組みです。

そこで使うDockerイメージは、軽量化を目指しました。Dockerイメージが軽量だと、本番へのリリース時間も短くなります。そして不要なパッケージが減れば、運用時のセキュリティリスクも減ります。不要なパッケージはなるべく含めないようにパッケージを選定したため、必要最小限の非常に軽量なDockerイメージを作成することができました。

同時に、それまでは手動で管理していた秘匿すべき情報、例えば、データベースの接続先情報などをイメージに含めないようにしました。GKEのsecretという、機密性の高いファイルをイメージにマウントできる仕組みを利用しました。

こうして作ったGKEでのインフラ環境で、サービスが正しく稼働しているか、メンバー全員で分担し、検証を行いました。業務的に重要なポイントを中心に、多数の検証ポイントを、１つずつ確認を進めました。検証の結果、うまく動かないところは設定を修正し、全ての検証を完了させました。

インフラ環境の検証が終わったあとは、今回のプロジェクトの大きな目的の一つである、オートスケールの設定を検証するために、負荷試験を行いました。通常時とピーク時のアクセス数を想定し、その負荷に耐えられるようアプリケーションのチューニングやGKEのパラメータ調整を行いました。GKEではCPU、メモリのrequest、limitが設定できます。それらの値とともに、オートスケールのpod台数と閾値を、複数回の負荷試験を行い調整していきました。

それらの過程で、アプリケーションのボトルネック箇所もあらたに見つかりました。また、ミドルウェアのバージョンアップにより破壊的変更が入り、アプリケーションの実装を修正しなければならない箇所もありました。GKEにリプレイスしたことによりログの出力方法を変更する必要があることもわかりました。それらの問題もひとつずつ解決していきました。

■手順書を作りリリース

リリースに向けた確認は終わり、残る作業は、リリース時の手順書作りです。作業を行う上で手順書作りは重要です。永続化されているデータの中から、移行を必須とするデータを選定し、それらを移行するための方法やツール作成を行いました。最短で且つ安全を期した手順を目指しました。机上でシミュレーションを複数回実施し、作業中に問題が起きた場合に、切り戻すための手順も用意しました。

2019年11月21日13時30分、リリース作業を開始しました。手順書も手厚く作成し、想定される問題も解決した上での作業だったこともあり、予定通りの時間で作業を終えることができました。しかし、想定外のことが起きるのはこの世の常です。移行後に特定のページの表示が重い現象が発生しました。問題の切り分けを行い、問題箇所を特定し、当日夜遅くにその問題を解決することができました。

■成果

私たちはこのリプレイスで大きな成果を出すことができました。当初を目的にしていた、インフラ費用や管理コストの削減を実現でき、新しい技術を採用したことで社内の技術力向上にもつながりました。

今後は、この技術を運用し続けなければなりません。運用するためのノウハウをこれから手探りで積み重ねていくことは、技術者の楽しみでもあります。

今後また別の問題を解決する際に他のメンバーが違う新しい技術を採用するといった流れをつくり、そこにチーム全体で全力で打ち込み、より良いプロダクト開発ができる環境を引き続き整えていくことで、世の中に大きな価値貢献ができる開発組織を目指しています。

■インフラ構成

最後に少し、テクニカルな話をしたいと思います。今回、リプレイスしたインフラの全体像及び、サービスの部分、CI/CD、監視等のパートごとの詳細を説明したいと思います。

下図は今回リプレイスしたインフラの全体像になります。真ん中の縦の部分ですが、上からロードバランサー、GKEを通り、ZUU online、MP Cloudのサービスへ抜ける部分、こちらは「サービス」の部分になります。

左から右へ向かって、GitHubからCloud Build、spinnkerを通ってGKEへ抜ける部分、こちらは「CI/CD」の部分になります。

真ん中GKEから右へ向かって、Logging、Monitoringを通ってslackへ抜ける部分、こちらは「監視」の部分になります。

サービスの安定稼働のため、弊社ZUU onlineのインフラは大きくこれら3つのパートで運用しています。

詳細は割愛しますが、興味のある方は、ぜひ調べてみてください。

おわりに

今回、弊社のインフラのリプレイス事例をご紹介しましたがいかがでしたでしょうか。興味をもって読んでいただけたでしょうか。文章で理解するのは難しいところもあったかと思いますが、ご理解いただけたら幸いです。

弊社にはまだまだ課題があります。今回はインフラのリプレイス事例を紹介しましたが、私もチームも日々課題解決に勤しんでいます。

弊社には挑戦できる環境があります。新しい技術を取り入れ、チーム一丸で切磋琢磨できる環境に共感いただける方は、ぜひ一度お話させていただけたらと思います。