LIFULLにはKEELという全社アプリケーション実行基盤があり、アプリケーションの運用に必要な多くのものを提供しながら広範的に開発者を支援しています。今回は、KEELプロジェクトを推進するソフトウェアエンジニア スペシャリスト 相原さんに、これまでの挑戦と今後の展望を伺いました。

新卒4年目、CTOへの直接提案から始まったKEELプロジェクト

2015年にLIFULLに新卒で入社してから、現在までのキャリアを教えてください。

2015年に新卒で入社をし、インフラ、バックエンドの領域からキャリアを始めました。入社4年目の時に、LIFULLの全社内製PaaS「KEEL」を作るプロジェクトを一人で立ち上げて、それ以来ずっとKEELのチームにいます。

全社内製PaaSは、全社の開発速度や品質を左右する大切な開発ですよね。なぜ新卒4年目の相原さんが1人で担当することになったのでしょうか。

そもそも僕がCTOに直接提案するところから始まったプロジェクトなんです。

当時はマイクロサービスでの開発が主流な時代で、LIFULLにおいても開発速度やメンテナンス性の向上を目的に、マイクロサービス化を推し進めていました。

一方で、マイクロサービス化は、チームごとに品質にばらつきが生じたり、開発する機能が重複したりするなどのデメリットもあります。分散システムやプラットフォームエンジニアリングを専門としている僕は、いずれは統合した全社基盤が必要になるのではないかと考えていました。それを、将来的にLIFULLで使う日が来ることをイメージしながら、プライベートで作ってみていたんです。

そんな中、僕が4年目のタイミングで、LIFULL HOME’Sを刷新する大きなプロジェクトを開始することになりました。そのときに、温めていたものを直接CTOに提案し、任せてもらえることになりました。

LIFULLでいつか使うことを前提にプライベートで準備！すごいですね（笑）CTOはどんな反応をしていましたか？

実はプライベートで作っていたものはCTOにも時折話していましたし、マイクロサービスのデメリットについても当然共通認識があったので、提案自体は驚かれることはありませんでした。ただ、これは後から聞いた話ですが、新卒4年目の僕に任せて問題ないかという点では一度立ち止まって考えたみたいです。

全社基盤に不具合があればLIFULLの事業活動がすべて止まってしまう、責任の大きなプロジェクトです。更に、影響範囲すべてを考慮しながら開発する高い技術力が求められる仕事なので、誰に任せるか慎重に検討するのは当然のことだと思います。でも、それまでの1つ1つの業務で必ず成果を出してきた点が評価されたのではないかと思います。

もちろんプレッシャーもありましたが、基盤開発であれば、社内で自分が最も適任だという自負もあったので、覚悟を決めて取り組みました。

KEELプロジェクト始動の技術的背景

改めて、KEELとはどんなものか教えてください。

KEELは、LIFULLグループ全体で利用することを目的としたKubernetesベースの内製PaaSです。

マルチテナントなクラスタで、下記のようなアプリケーションの運用で必要になる多くのものを責任範囲として提供しています。

その他にもPaaS体験を支えるコードジェネレータや認証基盤の開発に、ProxySQLやRedis, memcached, ベクトルデータベースクラスタの提供、アプリケーションフレームワークの提供とKEELへのアプリケーション移行など広範的に開発者を支援しています。
よくあるPreview Environmentを提供するKubernetes Custom ControllerやLinux Kernelレイヤのメトリクスを取得するためのeBPFプログラムをはじめとしてLIFULLに不足している機能があれば適宜開発する方針です。

既にLIFULLのアプリケーションのほとんどがこのKEEL上で稼働しており、新規開発のアプリケーションもこのKEELに載せることを前提に開発されています。

なぜKEELが必要だったのでしょう。

先ほど軽く触れましたが、LIFULLでは、オンプレミスからの AWS 移行を契機に、マイクロサービス化に踏み切りました。 これにより、サービスを適切な単位で切り分けてデプロイを独立化し、開発チームに権限を移譲することで、開発速度の大幅な向上を実現しました。しかし、年月が経ち新たな課題が見え始めました。マイクロサービス化による車輪の再発明と分散システムとしての難しさです。

それぞれのチームがロギング・監視基盤やデプロイフローを個別に構築したり、各アプリケーションごとに Retrying や Timeout を実装することにより、従来の体制と比較して重複する機能が多くなってしまいました。

加えて、下流のサービスに巻き込まれる形での障害も目立つようになり、分散したアプリケーションをうまく運用するという難しさにも直面することになったのです。

そこで、統一されたアプリケーション実行基盤を開発して分散システムの難しさを解決すると同時に車輪の再発明を防ぐことを狙うことにしました。それがKEELです。

結果として開発者がアプリケーションをローンチするまでの負荷が大きく下がり、効率を落とすことなくシステムの分離度を適切に保つことができるようになりました。

3人のスペシャリストが、基盤を作り、仕組みを作り、移行まで行う

同じような事例は、他社にもあるのでしょうか。

Kubernetesを利用している企業は多くありますが、マルチテナントなクラスタとなると少なくとも当時はあまりなかったような印象があります。

マルチテナント構成はリソース効率やメンテナンスコストに優れている一方で、テナント分離の技術的難度が比較的高いという特徴があります。

Kubernetesの元となっているGoogle Borgがマルチテナントを採用していたためGoogle社は恐らく似たような設計でしょうし、国内だとメルカリ社やサイボウズ社もマルチテナント構成を採用していたはずです。

Kubernetesをベースに内製PaaSを開発しているという点では、プラットフォームエンジニアリングがガートナーのハイプサイクルの黎明期を過ぎたということもあり、各社取り組み始めているころだと思います。

LIFULLの事例のユニークな部分はありますか？

内製PaaSの開発を通してプラットフォームエンジニアリングに早くから取り組んできたことから、ここに一日の長がある点ですかね。

代表的なところではPaaS体験を支えるコードジェネレータを開発しており、各種Kubernetes Manifestやアラート・ダッシュボードに加えてデプロイパイプライン・GitHub Actionsやアプリケーションカタログ・運用ドキュメントなどがコマンド一発で生成されるようになっています。

これにより開発者はわずか5分でProduction Readyにアプリケーションを本番環境にデプロイすることが可能です。
アラートのランブックに加えて運用ドキュメントも自動生成されるため、すぐに誰しもが運用を始めることができ、引継ぎ作業が不要になることで運用の俗人化を防ぐことにも繋がっています。

他のチームが全社に浸透させたい機能をこのコードジェネレータに対してContributeする文化も根付いていて、LIFULL全体の巨大なプラットフォームに成長させることができました。
インフラを作るだけではなくそれを簡単に使うためのツールもセットで作っていることと、それゆえに全社への浸透度が高いことは、LIFULLの特徴だと思います。

最近では社内で汎用AIエージェントと呼んでいる、いわゆるAutoGPT実装も開発しています。Web検索や画像生成は当然として、社内知識の検索や音声データの文字起こし・画像認識のほかに社内リソースへのアクセスを自然言語で命令できるというものです。

これによりこれまでのKEELでは支援できなかった開発者以外の生産性向上も狙っており、既にLIFULLグループ全体で職種問わず広く利用されるようになりました。

あくまで我々はプラットフォーマーなので、今後は監視基盤などプラットフォームとの統合を強めて、汎用AIエージェントによる障害対応の自動化や負荷テストやウォークスルーテストの自動化などプラットフォームエンジニアリングの未来に挑戦しようと思っています。

他にも特徴はありますか？

少数精鋭のチームで取り組んでいることでしょうか。
実は、KEELチームは僕1人から始まり、この5年間で人数の変動はありましたが、現在も3名のチームで開発をしています。能力密度を高く保つためチームサイズを大きくしすぎないようにはしていて、この規模のチームで、基盤を作るだけでなく、それを使う仕組みも作り、アプリケーションの移行も自分たちで行っているというチームは、他にあまり聞きません。

一緒に働く2人は、Webアプリケーションエンジニアとしても超一流です。
優れた基盤を作るためには、まず我々がその基盤のユーザーとして優れている必要があります。そのドメインのエキスパートでないと使われるソフトウェアを開発することはできません。「使われないソフトウェアに価値はない」とチーム内でよく話していて、我々がプラットフォームエンジニアリングに当初から投資してきたのもそういった考えからです。

直接的にWebアプリケーションの開発をすることはないけれど、仮にやることになったとしても誰にも負けないレベルで開発することができる。このように、ソフトウェアエンジニアとしてのカバー範囲の広さと深さのあるメンバーが集まっていることが、私たちのチームの自慢です。

技術の力で「あらゆるLIFEを、FULLに。」したい

相原さんのモノづくりへの情熱はどこから出てきているのでしょうか？

LIFULLのコーポレートメッセージ「あらゆるLIFEを、FULLに。」への共感が、僕の原動力です。
今でも鮮明に覚えているのですが、軸が定まらないまま就職活動をしていた頃、ある人に「暇人の暇潰しのためのプロダクトを作るのか、困っている人を助けるプロダクトを作るのか」と問われ、当時の僕は衝撃を受けました。表現は強かったですがとてもしっくりきたことを覚えています。そのうえで企業の経営理念を見たときに、LIFULLが目指す世界感に惹かれたので入社をしました。

今も思いは変わりません。スキルを磨き、そのスキルをもって自分にしかできない仕事をし、その仕事によって「あらゆるLIFEを、FULLに。」に近づいていく。こんなに面白くてやりがいのある仕事は、他にないと思っています。そしてプラットフォームエンジニアリングは成果にレバレッジを効かせられるという点で、「あらゆるLIFEを、FULLに。」を目指すうえで重要な領域です。

実は今、KEEL開始時と同じように、また新たな挑戦の種を温め始めているんです。未来を見据えながら新しい開発に取り組み、成果が出るのはとても楽しいです。

KEELチームの今後の展望を教えてください。

LIFULLのモノづくりを加速させ、ひいては「あらゆるLIFEを、FULLに。」を実現するために、チームの影響力を縦横に広げていきたいです。

具体的には、各アプリケーションを開発するエンジニアが「あらゆるLIFEを、FULLに。」に直結するコアな部分だけを考えられるよう、全社基盤でカバーできる範囲を増やしていきたいです。先ほど紹介したコードジェネレータの取り組みもその1つですが、他にもやりたいことはたくさんあります。

また、グループ会社へのKEELの導入も推進していきたいです。特に、世界中60か国以上でサービスを提供する「LIFULL CONNECT社」への導入は、LIFULLが世界中にインパクトを残すために必要不可欠だと思っています。

これらを実現するには、現在の3名体制で実現できる話ではなく、海外を含む多拠点開発チームに成長していく可能性もあります。チームの能力密度を保ちながら、大規模で個力の高いチームにしていきたいです。

最後に、就活・転職活動中のエンジニアの方々や、LIFULLに興味を持っている方にメッセージをお願いします。

先ほどお伝えした通り、僕は「あらゆるLIFEを、FULLに。」に共感して入社を決めました。その判断は正解で、今もそれが原動力になって仕事をしています。

エンジニアとして社会に貢献したい気持ちがある人にとって、LIFULLはその思いを実現しやすい環境だと思います。同じ志に向かって技術を高めたい方からのエントリー、お待ちしています！

参考情報

◇LIFULL採用サイト
◇LIFULL Creators Blog