LIFULL Creators Blog

LIFULL Creators Blogとは、株式会社LIFULLの社員が記事を共有するブログです。自分の役立つ経験や知識を広めることで世界をもっとFULLにしていきます。

LIFULL HOME'Sのページ性能を維持するための仕組みづくりについて

テクノロジー本部の布川です。

私の所属するチームではこれまで、ユーザ体験向上のためにLIFULL HOME'Sの高速化に取り組んできました。 本記事では、上記プロジェクトの一環として実施した、一度チューニングを行ったページの性能を将来に渡って維持するための仕組みづくりについて紹介したいと思います。

続きを読む

「IDRユーザフォーラム2023」参加報告

こんにちは、グループデータ本部データサイエンスグループの清田です。

LIFULLでは、不動産や住まい探しに関する研究の活性化や、AI・情報学分野での人材育成への貢献を目的として、学術研究者向けにLIFULL HOME’Sデータセットを2015年から提供しています。

日本における情報学の中核研究機関である国立情報学研究所(NII)が運営する情報学研究データリポジトリ(IDR)の枠組みを活用した取り組みです。

現在では、国内外の150を超える大学・公的研究機関の研究室にデータを提供し、数多くの研究成果も生まれています。

本記事では、2023年12月11日に開催されたIDRユーザフォーラムの様子をお伝えします。

続きを読む

年末の大掃除として行う開発ドキュメントの「断捨離」

エンジニアの松尾です。LIFULL HOME'S の売買領域でエンジニアのマネジメントを担当しています。

チーム開発やプロダクトの運用をしていくにあたって開発ドキュメントは重要です。LIFULLにおいても日々作成やメンテナンスをしていますが、運用にあたって問題もあります。今回はこれらを少しだけでも改善すべく、「断捨離」に取り組んだ話を紹介します。

  • ドキュメント管理の現状
  • 「断捨離」の意味
  • 開発ドキュメントの「断捨離」
  • 年末の大掃除
    • 個人ワーク
    • グループワーク
    • 試してみた結果
  • まとめ
続きを読む

GitHubトークン管理におけるセキュリティと利便性の向上

本記事は LIFULL Advent Calendar 2023 の17日目の記事です。 qiita.com

事業基盤のチームのマネジメントを担当している磯野です。
自他共に認めるGitHubおじさんとして社内では活動しています。

私たちのチームは開発生産性をより高めるため、開発エコシステムの改善に取り組んでおり、特にGitHubを中心とした生産性向上に注力しています。

今回はその取り組みの一環として、GitHub Actions においてマシンユーザーやAppsを減らしつつ、セキュリティと利便性を向上させるための施策について紹介します。

続きを読む

Kubernetesクラスタの可観測性の隙間を埋めるeBPF

KEELチームの相原です。

今回はeBPFを利用してKubernetesクラスタの可観測性の隙間を埋めている話です。

前回のエントリではLLMにうつつを抜かしていたので本業(?)の話をしようと思います。

www.lifull.blog

  • LIFULLの可観測性の現在地
  • eBPFとは
  • 可観測性の隙間
    • NAT Loopback
  • eBPFを実行するには
    • BPF CO-RE
  • libbpf-rsを利用したNAT Loopbackの検知
    • 1. (ユーザ空間) コマンドライン引数として受け取ったDNSをTTLごとに名前解決してIPアドレスを取得する
    • 2. (ユーザ空間) IPアドレスに変化がある度にカーネル空間で動くBPFプログラムにそのIPアドレスのリストを渡す
    • 3. (カーネル空間) Kprobesで tcp_v4_connect/tcp_v6_connect にフックを仕込む
    • 4. (カーネル空間) 受け取ったIPアドレスに対する tcp_v4_connect/tcp_v6_connect があればユーザ空間に対してその実行元のプロセスIDとコマンド名を返す
    • 5. (ユーザ空間) カーネル空間から受け取ったプロセスIDからKubernetes上のコンテナIDを取得する
    • 6. (ユーザ空間) 得られたコンテナIDとコマンド名とともに接続先をPrometheusのMetricsとして公開する
  • 最後に
続きを読む

社内向けAI botの運用で学んだ技術コミュニケーションのコツ

プロダクトエンジニアリング部の二宮です。

私は有料集客のデータを扱う部署の仕事をしながら、サイドプロジェクトとしてKEELチームとともにkeelaiという社内のAIチャットボットの開発にも関わっています。keelaiについての詳細は相原がこちらの記事で解説しています。

www.lifull.blog

keelaiはSlack上で動くAIチャットボットを含んだ "汎用AI(仮)" 技術スタックで、LIFULLグループのSlackユーザーおよそ1000人程度の中で月間200人以上に利用して頂いてます。これはけっこうな成功例と言っていいんじゃないでしょうか?

結果的にですが、keelaiの社内広報やサポートを担当することが多くありました。また私はエンジニア向けのQ&Aフォーラムを開設していること、ベトナム拠点との交流会の企画にも関わっていることから、社内の技術広報やコミュニケーションについて考えることが多くありました。そこで培ったノウハウや考えも含めて共有します。

続きを読む

OpenAI Assistants APIを使わずに無限にスケールする汎用AI(仮)を開発した

KEELチーム の相原です。

前回のエントリ で我々KEELチームはKubernetesベースの内製PaaSであるKEELを開発・運用する傍ら、LLMという新たなパラダイムの台頭にあわせてベクトルデータベースの提供や周辺ソフトウェアを社内向けに開発していることを紹介しました。

www.lifull.blog

あれから数ヶ月が経ち、現在私達はLIFULLのグループ会社全体に向けて汎用AI(仮)を提供しています。

もともと我々KEELチームはPlatform Engineeringの一環として、Kubernetesベースの内製PaaSであるKEELのほかにコードジェネレータによる一貫したPaaS体験を中心に様々なユーティリティをコマンドラインから提供するkeelctl, KEELが提供するプラットフォームのユーザ体験を向上させるブラウザ拡張のkeelextを開発してきました。

Platform Engineeringの責任は無限にスケールさせることです。

プラットフォーム・コマンドライン・ブラウザを手中に収めてソフトウェアエンジニアの生産性向上を盤石なものとした私達が次に目を向けたものが、職種問わずあらゆる業務上の課題を解決できる汎用AIでした。

そもそも社内のLLM活用が思うように進んでいなかった中で、まずは活用の背中を見せること、そして"無限にスケール"を目指す上で避けて通れない汎用AIというテーマにはスケーラビリティや信頼性に専門性を持つ私達が適任だと判断しました。

  • 今回目指す汎用AI
  • 汎用AI(仮) keelai
    • Agents
      • Function Callingの利用
      • マルチエージェントによるトークン消費の抑制
      • マルチエージェントにおける状態共有とベクトルデータベース
    • Bot
    • EmbeddingRetrieval
    • Evaluation
  • その後
    • OpenAI Assistants API
  • 最後に
続きを読む