システムの安定性と俊敏性(アジリティ)を高めるために、インフラやソフトウェア、運用方法について常に検討を重ねていく――「SRE(Site Reliability Engineering)」という名の下に、先進企業のエンジニアが取り組んでいる活動だ。

ソフトウェアの設計を見直し、クラウドなどの先進機能を積極的に活用しながらインフラ管理の自働化を進め、ボトルネックになりやすい人手作業を減らす。こうした大枠はどの組織でも共通するが、具体的な取り組みの内容は現場によってさまざまだ。何をどう変えると効果が見込めるのか、期待半分・不安半分で試行錯誤している状況だろう。

第105回 IT Search+ スペシャルセミナーは一休のCTO室所属エンジニア 徳武 聡 氏に、クラウド移行の過程を振り返りつつ、具体的な取り組みの内容を紹介していただいた。

一休 CTO室 徳武 聡 氏

会員800万人、ユーザーファーストを支えるシステム

2000年に誕生した高級宿泊サイト「一休.com」。2005年にマザーズに上場し、2007年に東証一部へ市場変更。その後も高い成長率を維持し続け、現在は800万人もの会員数を誇る。

「上質なサービス」の紹介というコンセプトの下、レストラン予約やホテルスパ予約などの姉妹サイトも手掛け、”尖った”マッチングサイトとして人気が高い。

ユーザーファーストを掲げ、サイト改善も頻繁に行う同社だが、以前のサイトは、契約データセンターの自社管理サーバ上で動作するトラディショナルなアプリケーションによって実現されていたという。

その一休が、クラウド移行を決断したのは2016年末のこと。徳武氏を中心とする約10人のエンジニアがプロジェクトに携わった。

システム刷新作業は2018年4月に完了。AWS(Amazon Web Services)へ完全移行し、データセンターの契約を解除したという。

インフラ変更をソースコードで管理

プロジェクト立ち上げにあたっては、「単に物理的な筐体が仮想マシンになっただけ、という移行には絶対にしないと決めていました」(徳武氏)と語る。

刷新した範囲は、アプリケーションサーバ、ビルド/デプロイパイプライン、ロードバランサー、メールサーバ、データベースサーバ、モニタリングと非常に広い。

例えばアプリケーションサーバはAWS Elastic Beanstalkに置き換えたうえで、Terraformを採用してInfrastructure as Codeを実践できる環境を整えた。

もちろんアプリケーションはステートレスなかたちにリファクタリング。AWS Elastic Beanstalkを活かせるよう巨大なアプリを分割する作業にも多大な時間を割いた。

こうした変更について徳武氏は、「インフラ変更に関する作業がソースコードで行えるようになったのは大きいです。システムエンジニアリングにGitHubやCI/CDといったソフトウェア技術を活かせる状況になり、インフラ管理の属人化が解消されました」と語った。

多岐にわたる改善の結果、2018年のインフラ起因インシデントは「0」。前年の「10」を踏まえると、大きな進歩を遂げている。

SREの目的を忘れるな

SREについて、本家 米Googleのエンジニアらが著した書籍には、さまざまなトピックスが記載されているが、徳武氏は「SREが障害を未然に防ぐための手段であることを忘れてはいけない」と強調する。

というのも、書籍に書かれていることをすべて実践しようとすると混乱に陥りがち。本来は手段であったエンジニアリングが目的化することも少なくない。

「技術、サービス、方法論が解決しようとしている課題を把握したうえで、その課題と自分たちの課題を突き合わせ、ベターな姿を描いていくことが大事です」――徳武氏はSREのポイントをこのように語り、技術者にエールを送った。

*  *  *

本稿では、徳武氏の講演スライドを提供する。

会員ログインのうえ、以下の資料紹介のリンク、あるいは記事末の「今すぐ資料をダウンロード」ボタン、「ダウンロードBOXに入れる」ボタンから入手してほしい。

講演資料の内容


講演資料は全92ページ。一休が実施したSREの内容が事細かに紹介されています。

AWSへの移行のみならず、Fastly、SendGridなどの外部サービスやOSSも活用し、文字通りインフラを大幅刷新した一休のプロジェクトの様子が、考え方とともに示されています。

<PDF内容>

  • エンジニアリング組織の体制
  • 一休でのSite Reliability Engineering
  • Site Reliability Engineeringとしてのクラウド移行
  • アプリケーションサーバの課題に対する解決策
  • Terraform+AMIでInfrastructure as Codeを実践
  • アプリケーション大規模リファクタリング
  • ビルドデプロイパイプライン なぜ不安定?
  • CDNサービス見直しでFastlyを検証してみると
  • SMTPサーバの運用自体をなくしたい
  • クラウドサービスのメトリクスはDatadog
  • アプリケーションの性能はNewRelic
    ……など

>> ダウンロードはこちらから