日本のSREの火付け役ともなったエンジニアが貫く信念 ─ すべてはログの向こうにいるエンドユーザのために

こんにちは、はじめまして。さくらインターネット株式会社の長野雅広@kazeburoです。Webの業界に入ったのは学生だった2000年頃で、キャリアは20年以上になります。おそらくこの業界でも長い方ではないでしょうか。20年の間にmixiやlivedoor、メルカリといった企業で働く機会を得て、どの職場でもサービスの裏側にあるインフラや、Webアプリケーションの運用を支える仕事、今ではSREと呼ばれるような業務に携わってきました。

そして今年の1月から、さくらインターネットにてクラウドを中心にサービスの開発を行っています。つまり、インフラやクラウドを利用して一般のお客様向けにサービスを作るという仕事から、クラウドを作ることを仕事にする、という選択をしました。

この記事では、どのような経験からSREとして働くようになったのか、また現職に至る選択をした経緯について語りたいと思います。加えて、創設に関わったISUCONについてもどのような経緯で始まり、これまでどう参加してきたのかを紹介します。

データセンターに行く開発者から行かない運用エンジニアに

私がWebの業界で働き始めたのは大学生のときでした。高校生の頃にインターネットというものを知り、大学入学後にインターネットを仕事にしようとイベントに参加するなど、活動しているうちにできた知り合いが興した会社、今でいうスタートアップでWebサービスの開発などを行ったのが最初のキャリアです。

小さな会社でしたので、数人で全てをこなさなければなりません。どんなサービスを作るのかを考え、実装し、サーバを構築してデータセンターに設置し、日々の運用も行いました。夜間にタクシーでデータセンターに駆けつけることも何度かありました。

そんな中で運良くトラフィックが多いサービスになり、今度は負荷対策に追われることになりました。アプリケーションをmod_perlで高速化させたり、まだ事例も少なかったリバースプロキシを導入したり、さまざまな運用の工夫をしつつ、負荷が下がったところで新機能に取り組むといったサイクルでした。今思えば、このときに運用への関心が強くなったのでしょう。

当時の開発で主に利用していた言語であるPerlには、livedoorやはてなといったWeb関連企業のエンジニアを中心としたコミュニティがあり、IRCや勉強会で活発な情報交換が行われていました。そこで目にしたのは、日本のトップサービスを開発しているエンジニアが、日々の業務やちょっとした作業のためにPerlのモジュールを作成し、呼吸するようにOSSとして公開にしていく姿でした。これが私に大きな影響を与えました。

その後、YAPC::Asia 2006 TokyoというWeb技術カンファレンスをきっかけに、盛り上がりを見せていたSNSの1つを運営する株式会社ミクシィに転職しました。mixiでは、アプリケーション運用チームに所属しました。それまでの経験をより生かせるよう、開発者から運用専門のエンジニアになる選択をしたのです。前職と違い、データセンターで作業を行わない運用エンジニアです。

画像配信の最適化、memcachedによるスケーラビリティ向上、サーバ構築やデプロイメントの改善など、さまざまな業務を担当しました。また、それを勉強会やカンファレンスで発表する機会も得ました。プログラミング言語に関する話題だけはなく、どのようにOSSを使ってWebサービスを動かしているのか、スケーラビリティを改善しているのか、そういったノウハウの勉強会も開かれ、さまざまな会社のインフラエンジニアとも交流できました。

何かしら問題を解決するソフトウェアをOSSとして公開したり、ノウハウや経験を勉強会で発表したり聞いたりすることは、今では習慣化して、私の行動指針の1つにもなっています。

▲ 2017年11月に開催されたMonitoring Seminar in mercariで発表中の筆者

憧れの職場での運用経験から生まれたISUCON

mixiでOpenSocialによるソーシャルアプリの負荷対応が落ち着いてきた頃、株式会社ライブドア(後のLINE)に転職しました。livedoorのエンジニアはWebに関わり始めた頃から憧れの存在でもあり、一緒に働けることが不思議でした。

livedoorでは、ポータルのサービスで幅広く運用にあたりましたが、中でも時間を使ったのがlivedoor Blogです。情報発信の体験が良くなり、お客様の書いた記事が多くの読者に届くよう、さまざまな改善を行いました。特に人気の高いブログにアクセスが集中してもダウンしないようデータベースのチューニングを行ったり、キャッシュを有効的に使うようアプリケーションにも手を入れました。この経験がISUCONにつながります。

当時、Webアプリケーションのチューニングを行うコンテストは既にありましたが、アプリケーションには手を入れられず、ミドルウェアなどを変更するだけのものでした。これに当時の同僚が「我々の業務はこうではない」という感想を持ったことから、インフラからアプリケーションまで何でもアリなチューニングコンテストを発案し、開催されたのが、2011年のISUCONです。このときは、お題となるWebサービスの作成、ベンチマーカのチューニングなどを行いました。

そして2021年、ISUCONは11回目の開催となりました。ここまで長く続いてきたのは、取りまとめを行ってきた櫛井さんをはじめとするLINE株式会社のスタッフや、毎回の問題作成を担当してきたエンジニア、そして参加者の方々のおかげです。

ISUCON11では予選参加申し込みが2時間で上限の600チームに達するなど、回を追うごとに人気が高まっているように感じます。私は初回と第2回で出題を担当し、ISUCON3と4では参加者として優勝することができました。ISUCON9の予選で再び出題を引き受けましたが、その間には予選落ちも何度か経験し、参加のモチベーションを失いかけることもありました。しかし、新しい技術の獲得やチャレンジの場と考え直し、毎年参加しています。

ISUCONはなぜこれほど人気があり、また私も含めて参加し続けているのでしょう? それは、エンジニアが日常的に業務で行っていることを、8時間という限られた時間に、最大3名という限られたチームで、集中してチューニングに取り組む非日常な経験。また、普段の業務では分かりづらい取り組みの結果が即時にスコアとして反映されることで、中毒性もある楽しさがあるのではないかと思います。

ISUCONの過去の問題は全てGitHubで公開されており、それをもとに各社でエンジニアのスキルアップのために社内ISUCONが開かれたり、学生にとっては普段なら体験できない負荷への対応を学ぶ良い資料となるなど、業界全体の底上げに役に立っているのではないかと、その始まりに関われた人間として少し誇らしく思っております。

サイトの信頼性をエンジニアリングすることが必要な時代

livedoorがNHN Japanと経営統合し、社名がLINEに変わり、大きな組織へと変化していく頃、まだエンジニアの間でそれほど名前が知られていなかったメルカリに転職しました。当時のメルカリは社員数もまだ100人に満たないほどで、エンジニアもそれほど多くはいませんでした。

メルカリはmixi時代の同僚が既に働いていたことで興味を持ったのですが、アプリを実際にインストールして使ってみると、出品されて間もない商品にすぐにコメントが付き、ものすごい速さで売れていくことにまず驚きました。個人と個人が商品を売り買いするフリマアプリが、人と人をつなぐコミュニケーションとしても成り立っているという感覚を得たことが、ここで働く選択に大きく関わっています。

livedoorでブログ、mixiでSNS、その前もコミュニティサイトを運営しており、人と人のコミュニケーションや情報発信を支える仕事をずっと選んできました。コミュニティにおける会話や情報のやりとりなど、お客様の体験をより良くしていくことで社会もより良くなると信じ、キャリアを重ねています。メルカリも同じ考えで選択しました。

メルカリではインフラチームに属しながら、とてつもない速度で拡大するサービスを支えるため、新機能の開発以外でできることは何でも取り組んできました。その頃、Googleに勤めていた知人から、GoogleにSRE(Site Reliability Engineering)という職種があることを教えられました。Googleの巨大なシステムを走らせながら改善し、信頼性を上げていくところにひかれ、メルカリのインフラチームを「SREチーム」とするように提案しました。

まだ日本ではSREという言葉がそれほど知られておらず、私がエンジニアリングブログに書いた記事で知った方も多かったようです。チームメイトとともにSRE Meetupを開催するなど、日本におけるSREの火付け役の1つになったのではないかと思います。

今ではSREに関する日本語の書籍も出版され、各社のSREチームについても技術ブログなどでたくさんの記事が書かれています。それだけSREについての情報が求められる時代になってきたということでしょう。

Web業界が大きく、社会を支えるインフラとして重要性を増し、技術も広く複雑になり、関わるエンジニアも圧倒的に多くなっている現在では、組織も大規模化し、異なるバックグラウンドを持った人間が集まってサービスを作り上げるようになっています。そのため、サイトの信頼性を、技芸ではなく再現可能なエンジニアリングとして成り立つようにしていくのは必要です。そのため、エラーバジェットやSLO、SREを開発チームに参加させるEmbedded SREなど、既にある事例やベストプラクティスを参考にするのが重要であることは間違いありません。

ただ、これまでOSSや勉強会などを通してさまざまなことを学んできた経験を思うと、現実で発生した技術的問題を解決した方法、ちょっとしたものであっても課題を解決した新しいソフトウェアの開発、OSSの活用など、社内や開発組織に閉じない事例もまだまだ見てみたいと思ってます

▲ 2018年3月に実施されたYAPC::Okinawa 2018にて発表準備中の筆者

toCからtoBへ ─ お客様のDXを支える新しいチャレンジ

2021年1月から、現職であるさくらインターネットに勤めています。これまでのキャリアは、どちらかといえばtoCなWebサービスを運営する企業でしたが、さくらインターネットはtoBのインフラを提供する会社です。新しいチャレンジを選択しようと、クラウドを使う側から作る側に環境を変えました。

メインの業務として「さくらのクラウド」のマネージドサービスの改善・開発を行っています。ロードバランサーやDNS、監視など、これまで培ってきた技術を生かしながらサービスを開発しています。お客様からの問い合わせをうけて、クラウドのインフラ側でのトラブルやお客様の設定漏れを調査したり、他のサービスの利用について提案したり、さらに新機能の開発など、できるだけ幅広く関わるようにしています。

単に機能を開発するだけでなく、クラウドのコントロールパネルへの組み込みから、リリース後のお知らせやマニュアルの更新なども一通り行っています。そして毎週何かしらリリースすることで、クラウドのサービスが進化し続けるイメージを、お客様にも社内にも作っていきたいと考えています。

加えて、SREとしての取り組みも期待されています。サービスのメトリクス収集、監視や継続的な改善、またチーム全体としてサービスの信頼性を向上させる取り組みも、常に課題として意識しています。

これまでであれば、チームや個人の改善の取り組みは、お客様であるユーザにほぼ直接届くような環境にいたわけですが、現職では作ったものがそのまま広がってはいきません。お客様のニーズを適切に捉え、機能としてタイミングよくリリースしていかなければ、使っていただくことはできません。

機能の開発だけではなく、お客様の課題を聞き、それを発展的に解消させることで、お客様のDX(Digital transformation)の実現、またお客様のお客様、つまりエンドユーザの良い体験に結びつけていきたいと考えています。

ログの向こうにいるエンドユーザの問題を解決するために

一行のログの向こうには、一人のユーザがいる」というのは、クックパッドに在籍していた井原さん(現・ビットジャーニーCEO)によるブログ記事のタイトルですが、とても好きな言葉です。

これまでのキャリアで運用してきたWebサービスには、運良く多くの人が訪れ、他の人とのコミュニケーションや情報発信の場として利用されてきました。サービスを利用するお客様が残念に感じるような体験を減らして、できるだけ良い体験をしてほしい。お客様がやりたいことを、やりたいと思ったタイミングでできるようにする。それによって社会が良い方向に進むのではないかという考えを持って取り組んできました。

サービスがなかなかうまく動かず、苦しい時間を過ごすこともありました。長く続けるには楽しみも必要です。解決するアイディアを自分たちで考えて組み込み、うまく動いたときに得られる達成感は楽しみの1つであり、OSSやISUCONの活動でもその楽しさを広めていけたらと思っています。

インターネットを活用して情報発信を行おうとする方、DXにチャレンジする方やそれを支えるエンジニアを、微力ながら今後もサポートしていきたいと考えています。

編集:はてな編集部

YAPC::Okinawa 2018の写真は、Japan Perl Association (JPA)によりCC-BY-SAでライセンスされています。