あのGoogleが最初に提唱した、Webサイトの安定性と信頼性を高めるインフラ構築の新手法ーー。そんな説明はもはや不要に思えるほど、日本のネット界隈でも広がりを見せているSRE（Site Reliability Engineering）。

この2〜3年の間に、ベンチャーから大企業まで幅広いネット企業が専任チームを設けるようになり、インフラエンジニアはサービスの開発・発展に対してより直接的な影響を持つようになった。

クラウドソーシング大手のランサーズは、成長期からSREの方法論を導入してきたという。

その甲斐あってか、2016年に行ったデジタルマーケティングサービス『Quant』（※）のリリースを皮切りに、CtoCのスキルシェアサービス『pook』、エンジニア向け常駐案件紹介サービス『LancersTOP』など続々と新事業を生み出しており、売上も2016年は21億円、対前年比で約160％と順調に伸びている。

※『Quant』を運営するランサーズの100％子会社クオント株式会社は、ソリューション事業をランサーズに移管した上で2018年3月30日にグリーへ株式譲渡している。

今年2月20日、その過程でやってきたことを披露するエンジニア向け勉強会「事業の多角化を支えたランサーズ的SRE術」をTECH PLAYで開催したランサーズは、どんな壁に突き当たり、どう乗り越えてきたのか。その概要を紹介しよう。

わずか4名のメンバーでSREを実施

勉強会の冒頭、「ランサーズのこれまでとこれから」をテーマに語った執行役員CTOの横井聡さんによると、同社の従業員数は約160名（2017年4月時点）で、うちエンジニアは約30名規模になっている。

その中で、SREに取り組むインフラエンジニアは、2018年2月時点でわずか4名。少数精鋭のチームで、前述した新規サービスや屋台骨であるクラウドソーシングサービスのランサーズ、その他企業サイト・広報ブログなどを支えている。

SREを始めたきっかけは、「インフラチームがインフラしか見ないという状況にはしたくなかったから」と横井さんは言う。

Webデザイナーとしてキャリアをスタートした後、SIerでの大規模システム開発や、コンサルティング会社での新規Webサービスの企画・開発・運用に携わってきた横井さん

「ただ、SREという名称を採用したからといって、インフラエンジニアの役割が劇的に変わったというわけではありません。今までもやっていたことに、名前を変えて光を当て直すことで、会社として『SREは事業の根幹を支えるもの』と表明したのです」（横井さん）

横井さんはランサーズに入社する前、いくつかの企業を転職する中でデザインからフロントエンド開発、バックエンド開発と幅広い業務に携わってきた。そんな背景もあってか、CTOとしてエンジニアチームを運営する際も、分業による一体感の喪失をなるべく避けるように心掛けているという。

こうした横井さんの考えは、同社のインフラ構築・運用業務にも反映されている。

技術的負債を抱えない「攻めのインフラ構築」

SREチームの立ち上げから携わってきたインフラエンジニアの金澤裕毅さんは、チームのミッションを以下のように述べる。

「我々のSREチームでは、一般的にSREとして認知されている業務以外に、ランサーズ独自の価値観に基づいた業務もいくつか担当しています。つまり、サーバ運用や定型業務の自動化、サービス改善のような仕事に加え、開発環境の支援やサーバー費用の削減など、スタートアップの成長に必要だと考えられる施策を横断的にサポートしているのです」（金澤さん）

2013年にランサーズへ入社した当初は、インフラエンジニアが自分1人だけだったと語る金澤さん。JAWS UGの山形支部に所属してコミュニティ活動も行っている

その取り組み詳細と、各プロセスで行ってきた施策は当日の発表資料（以下のSpeaker Deck）に詳しいが

>> ランサーズで積み重ねたSRE的取り組みとこれから（Speaker Deck）

主な方針として、

【1】セキュリティ対策を兼ねて言語やツールは「最新サービス」「最新バージョン」に追従する（旧バージョンを無理にカスタマイズしない）

【2】定型作業を自動化するだけでなく、他のチームに「委譲」できる仕組みにする（インフラチームを介さず、自分で完結できるような環境構築をする）

【3】インフラチームを開発のボトルネックにしない

などを重視してきたという。

これらは、サービス開発のスピードを担保することと、データ解析のような「ビジネスサイドでも常に必要とされる仕事」をエンジニア以外の誰もが行えるようにするのが狙いだ。

例えば【1】の「言語やツールは最新バージョンに」を愚直に貫くことで、拡大中のエンジニアチームに新入社員が入って来た時も生産性を下げずに仕事をしてもらえるというメリットが生まれる。

「また、オーナー不在で生き残っている機能や効果の薄い機能を社内調整した上で削除したり、古くなったコードを削除するのも我々の役割です。それによって生産性の向上やサーバ費用の削減につながります」（金澤さん）

こうして、技術的負債を抱えない「攻めのインフラ構築」と資金面での「守りの姿勢」の両方を同時進行で進めることで、サービスのみならず企業全体の成長を下支えするチームとして存在意義を高めてきた。

今後は、

• PHP + CakePHP、Amazon Aurora MySQLのバージョンアップ
• データ分析基盤の構築（ログのリアルタイム解析、過去ログのAthena対応etc.）
• 開発環境で採用しているDockerを本番環境にも適用し、アプリエンジニアが開発、リリース、運用をすべて行える仕組みに
• 合わせてAPI化も進めて言語に依存しないサービス運用環境に
• マイクロサービス化、サーバレス化も適宜進める

などを実施しながら、そこで培ったノウハウをランサーズ以外の他サービスにも広めていくのが目標だと語る。

より便利なツールを試しながら開発のボトルネックを潰す

ただ、横井さんや金澤さんが説明したようなミッションを、4名という少人数のチームで進めてくのは口で言うほど簡単なことではない。インフラチームが「開発のボトルネックにならない」ためには、スケールし続けるサービスをいかに少ないコストで支えていくか？ に知恵を絞る必要がある。

その実践例の一つとして、インフラエンジニアの平塚貴之さんは、CtoCのスキルシェアサービス『pook』におけるAmazon EC2 Container Service（以下、ECS）導入の工夫を説明した。

金融、官公庁向けのオンプレミスインフラ運用から、自社サービスのクラウドインフラエンジニアを経て、2016年3月ランサーズに入社した平塚さん

ECSはDockerコンテナの実行・管理を簡単に行うことのできるスケーラブルなコンテナ管理サービスとして知られているが、同社では最初、OSSのオーケストレーションツールであるTerraformでコンテナ管理を行う構想だったという。

「もともとランサーズはTerraform + Ansibleを使った自動構築化を進めていたから、というのが理由でした。ただ、新規サービスの数が増えるにつれて、インフラチームの労力も増え続けるという課題もありました。障害対応のたびに手を動かす必要があり、またOSSのバージョンを上げる際にうまく動かなくて戻したり......という手間が発生します。そこで、ECS-CLIでDockerコンテナを作成・活用する環境に切り替えました」（平塚さん）

その際の主な判断基準は2つだったと平塚さんは続ける。

「一つは開発のスピード感を担保しやすいから。プロトタイプベースでPull→Build→Upのサイクルが回せるという点が特に魅力的でした。そしてもう一つは、Immutable Infrastructureを志向してインフラを刷新していく流れに即していたからです」（平塚さん）

実際に『pook』で構築したシステムアーキテクチャなどについては、当日の発表資料（以下のSpeaker Deck）にまとまっているので、ぜひ見てほしい。

>> Lancers x ECS（Speaker Deck）

基本的な考え方は、PaaS提供企業Herokuの社員がまとめて世界的に知られるようになった、モダンなクラウドアプリケーション開発の方法論「Twelve-Factor App」を参考にしていると平塚さんは言う。

また、デジタルマーケティングサービス『Quant』のサーバーサイド開発を担当してきたエンジニアのameshoさんは、全社的な開発効率アップを狙ってTreasure Data社のOSSワークフローエンジン『Digdag』を導入した事例について説明した（当日の発表資料は以下のSpeaker Deck）。

>> 52 weeks after Digdag operation（Speaker Deck）

携帯公式サイト、広告配信系の開発などを経て、2016年12月にランサーズに入社したameshoさん。Ruby on Rails、Goを使う

『Digdag』はバッチ処理やログのバックアップなど、定期的に自動実行するジョブの管理を可視化するツールだ。『Quant』では、主にバッチ処理時間の可視化と運用の効率化を目的に使われた。

「Digdagを導入する前はcronを使ってジョブを自動実行していましたが、運用フローの不透明さがあってジョブの実行タイミングを把握しづらいという課題がありました。そこでDigdagを導入することで、管理画面を見るだけでどのサーバをキックしているかが一括して分かるようになりました」（ameshoさん）

これによって、バッチ処理を設定した人以外も、「どの処理がいつ始まり、実行中はどのくらい時間がかかっているか？」をビジュアルで把握しやすくなったとameshoさんは話す。

「その他、上司や同僚に口頭で説明しなくてもよくなりましたし、コードをガチで書かない人（例：クエリだけ書いている人とか）にとっても、既存の設定ファイルがあれば使い回しで済むので手間を省けるようになりました」（ameshoさん）

こうして全般的な状況把握がしやすくなったことで、開発チーム全員の認識が合うようになり、「今ではdigdagを中心に開発が進んでいく感じになってきた」という。

チームや会社の負担を、より便利なツールを試すことで改善・軽減していくことも、SREの大事な役割ということだろう。