【TECH PLAY Data Conference 2024】営業部門と挑むデータの民主化について発表しました

レバレジーズ株式会社 データ戦略室の森下です。

2024/01/25にTECH PLAY Data Conference 2024にて『営業部門と挑むデータの民主化』について発表したので、そのスライドを共有します。

営業人員が多い当社において、データの民主化にどのように取り組み、データ分析の専門家だけでなく、全社員がデータに基づいた意思決定を行い、成果を向上させた取り組みについて紹介しているので、是非ご覧ください。

イベント概要: techplay.jp

We are hiring

現在レバレジーズでは一緒に働いてくれる仲間を募集しています。ご興味のある方は、以下のリンクからご応募ください。

エンジニア採用ページ: recruit.leverages.jp

データエンジニア採用ページ: hrmos.co

第一回24時間AIハッカソンで準優勝しました

はじめに

テクノロジー戦略室クロスエンジニアリングチームの小林京輔です。業務では主にフロントエンドエンジニアとして、複数チームでフロントエンドのレビュー、ペアプロをしてます。

先日、社内のエンジニアと一緒に参加した(株)サードウェーブ主催第一回24時間AIハッカソン(2023年11月3・4日)で準優勝することができたので、ハッカソンで作成したアプリについて紹介したいと思います。

ハッカソン:connpass.com 記事:forest.watch.impress.co.jp

スライドp1

スライドp2

スライドp3

開発したアプリ

せっかく作るなら社会課題を解決するようなアプリケーションを作ろうという話になり、最終的に日常生活におけるストレスや精神的な負担を軽減し、誰もがいつでもどこでも気楽にアクセスできるパーソナルヘルスケアAIと銘打って「Kiraku」というアプリを24時間で作りました。

以前、看護ケアと現象学的研究を読んだことがあり、現象学的ケアという概念が新鮮に感じられました。

症状について対処するのではなく、患者さんの意向に沿った形でケアを行うこと(現象学的ケア)は、現象学的な文脈における「志向性」に着目した方法だと考え、現象学の流れを汲んだ概念を社会に実装したいという思いがありました。

上記を踏まえて、作成したアプリには大きく分けて2つの画面があり、問診画面、チャット画面があります。

問診画面では、いくつかの設問に答えてもらう形で、ユーザーの傾向を判定しました。

まずは精神的な悩みを抱えたユーザーに対する理解が必要だと考え、直面している問題に対して寄り添いを期待するタイプと、具体的な課題解決を求めるタイプの2つを想定し、プロンプトデザインをすることで問診を行います。

チャット画面では、各タイプに応じた応答をするようにプロンプトを書き、応答させるように設計しました。 寄り添いを期待するタイプのユーザーに対しては、常に共感とカジュアルな会話で悩みを和らげるように応答させ、具体的な解決を求めるユーザーに対しては問題解決に焦点を当てた直接的な質問とアドバイスをするようにし、ユーザーの傾向に合わせてパーソナライズされたチャットボットを作りました。

chat

さいごに

今回、人生で初めて参加したハッカソンでしたが、24時間という短時間で動くものが作れ、また準優勝という結果に結びついたことは素直に嬉しかったです。 また、深夜まで残ってくれたメンバーと一緒に開発して、組織として一つの目標に夢中になれたことは貴重な体験になりました。

レバレジーズでは社会課題を技術で解決していきたいエンジニアを募集しています。 興味のある方のご応募をお待ちしています!

開発者の、開発者による、開発者のためのインフラ監視への取り組み

こんにちは!レバレジーズ株式会社テクノロジー戦略室SREチームの蒲生です。 Datadog導入と監視のイネイブリングによってインフラ監視、アラート運用を開発者向けに民主化した事例を紹介します!!

この記事で伝えたいこと

  • インフラ監視をみんなでやるのいいぞ
    • サービスのスケールに柔軟に対応できるぞ
    • インフラのことまで考えて開発ができるぞ

↑の状態を達成するためにやったこと

  • 監視のイネイブリング
  • 監視による開発者への負荷軽減

インフラ構成が簡単に肥大化、複雑化する時代になってきました。 日々成長する事業を支えるために増えていく新規のマイクロサービスやスケールアウトされるサーバーに対して監視の設定をしていくことに悩んだ経験はないでしょうか。 私が主に担当しているレバテックの開発では、インフラ監視に開発者が携われる体制にすることで高速に変化していくインフラ構成に対して柔軟に対応できるようになりました。

当時の課題

当時の開発では以下のような前提と課題を抱えていました。

前提

アーキテクチャ

レバテックではAWSのEC2のモノリスアプリケーションからECSなどサーバーレス環境にマイクロサービスとして切り出していくリプレイスプロジェクトが進行中でした。

監視体制

当時の監視ツールはAWS CloudWatchを使用していて、CloudWatch AlarmやLambdaからメトリクスのアラートやエラーログをSlackに流すようにしていました。

アーキテクチャ図

課題

開発スピードに対して監視の対応が追いついていない

前提にある通りECSやLambdaを利用してマイクロサービスに切り出していくため インフラのリソースがどんどん増えていく状態に監視の設定や体制が追いついておらず、計測したいデータが取得できていませんでした。

インフラ関係のインシデントの多さ

アクセス負荷やデータ量の変化、不適切な実装によるインフラリソースへの負荷が原因でインシデントが発生してしまうケースが散見されていました。

インシデント発生時にかかる調査工数の肥大化

インシデントが発生したときにログやメトリクスを利用して調査を開始するのですが 先に述べたように取得できていないデータがあったり監視体制が整っていないこともあり 調査工数が肥大化して解決までに時間がかかっていました。

課題分析

当時の課題を以下のようにそれぞれ原因分析してみました。

監視対応の属人化

監視の設定や運用ができる人が社内で限られていて 追加されていくインフラの多さに対してボトルネックになっていました。 設定にかかる負荷が高いため設定漏れなどで取得していないデータがありました。 実際の作業に関する暗黙知だけでなくどの項目に監視の設定をすればいいのか、メトリクスの相関をどう見ればいいのかなどの知見の共有が足りていない状態だったと思います。

インフラリソースの使用状況の曖昧さ

実装者からみてリソースの使用状況が把握しづらい体制でした。 インフラのリソースが普段どのくらい使用されているのかを意識するタイミングが少なく、リリース後しばらく経って変化するメトリクスなどには気づきにくい状態だったと思います。 また当時のCloudWatchだと使い慣れている人でないとデータやメトリクスへのアクセス性が悪く、使用状況をぱっと確認できる手段がなかったのも曖昧になった原因となっていました。

調査時に発生するコミュニケーションコストの肥大化

当時監視設定やメトリクスのモニタリングをSREチームが担当することが多かったのですが、実際に開発をしているのは開発チームというサイロ化した状態でした。 インシデントが発生した際に異変に気づき調査を開始するのはSREチームだけど 何がリリースされたのか、コードがどう実装されているのかまで深く把握していないので開発チームと連携を取る必要があり、そこでコミュニケーションコストが発生していました。

解決策

当時知識があったわけではないですが今から振り返るとDevOpsのCALMSフレームワークでいうC(Culture)、A(Automation)、S(Sharing)を特に意識して解決策を考えたように思えます。

  • 監視設定、運用の負荷軽減

インフラ監視設定の自動/半自動化を進めることで設定漏れと全体の工数を減らし、インフラ監視の知識がない開発者でも設定ができるような状態にすることで属人化の解消を目指しました。 またDatadogの導入によってメトリクスやログの可視性を上げてデータへのアクセス性を向上させました。

  • 監視のイネイブリング

開発チームと一緒にメトリクスやアラートを確認する機会を定期的に作って、開発してリリースしたものがインフラやサービスにどう影響を与えているかを把握してもらうようにしました。 それによって開発者が監視設定や普段のモニタリングを行えるようにして、インシデント発生時に開発者の中である程度対応が完結できるようにしました。

具体的な施策

Datadog導入による監視設定、運用の負荷軽減

普段の設定、運用にかかる負荷を軽減するために 監視SaaSツールであるDatadogの導入を行うことでインフラ監視設定の自動/半自動化による設定工数の削減とメトリクス、ログの可視性向上を進めました。 それまで使用していたCloudWatchでは当時だと取得したいメトリクスの不足や統一的なアラート設定がしにくい、ダッシュボードのUIの使いにくさなどの課題があり、自動/半自動化を進めにくい状態だったのでこのタイミングでツールの切り替えを決断しました。

Datadogのワンちゃん

クラウドのリソースに監視用のタグをつけるだけで自動でDatadogにデータを送れるようにし、 新規のサーバーやマイクロサービスに対してはIaCツールによってコード化することで設定にかかる負荷を軽減して開発者によってインフラ監視設定を自走できるようにしました。 それによってSREチームやインフラに詳しい人がいなくても監視設定が進むようになりました。 また監視用のダッシュボードとログ検索機能を用意して、開発者が確認したいタイミングでぱっと見れるようにデータへのアクセス性と可視性を向上させました。

定期的なメトリクス確認会実施による監視のイネイブリング

開発者に監視の知見を深めてもらって運用できる状態にするために メトリクスダッシュボードを使って開発チームと一緒にメトリクス確認会を週次で実施しました。

まず先述したDatadogを使って各サービスごとにダッシュボードを作成し、開発者がいつでもインフラのメトリクスやログを確認できる状態にして そのダッシュボードを利用して週次で開発チームと週次でメトリクスやアラートを確認するメトリクス確認会を実施しました。

ダッシュボード

はじめはファシリテーションを私が行ってメトリクスの異常値や状態化したアラートなど会の中で確認したほうがいいものをシェアして、それらに対する調査や改善などのネクストアクションを出すまでを話す時間を作りました。 それによってリリースされたどのコードがインフラやユーザーに影響を及ぼしたかメトリクスやアラートの確認を通して開発者が把握して異変が見つかったら修正行動に移せるようになりました。

Slackでメトリクスについて話されているスレッド

開発者がある程度慣れてきたらファシリテーションをだんだん委譲させることで、SREチーム抜きで会が回るようになっていきました。 今ではインシデント発生時のアラートへの1次アクションは開発チームが行っています。

まとめ

監視設定の負荷が軽減されて開発者が運用に関わりやすい状態になり、サービスのスケールにインフラ監視が追従できるようになりました。 さらに、開発者が週次でメトリクスやアラートを確認する機会を作ることで、開発者が普段の開発がインフラレイヤに及ぼしている影響を把握し、アラートへのアクションを開発チーム内である程度完結できるようになりました。

インフラ監視の民主化の重要性を示すひとつの例となったのではないでしょうか。 なによりSREチームの私としては開発チームの方と共通言語を使ってサービスの課題について話し合えるようになって仕事が楽しくなりましたし 開発チームが独自に監視やログの設計を見直している活動を見たときは嬉しくなりました。

改めてここで伝えたいことのおさらい

  • インフラ監視をみんなでやるのいいぞ
    • サービスのスケールに柔軟に対応できるぞ
    • インフラのことまで考えて開発ができるぞ

今回は監視、アラートに関する取り組みでしたが他にも色々な取り組みを通じてSREチームとしてプロダクトの信頼性を保ちながらより質の高いリリースを可能な限り早くできる状態を目指して頑張っていきます!!

レバレジーズではサービスの信頼性を高める活動をしていきたいエンジニアを募集しています。 興味のある方のご応募をお待ちしています!

AWS re:Invent 2023 グルメ紀行 後編

前日 ~ 2日目は前編に書いています。 こちらの記事は、3日目 ~ 帰国までの記事です。 技術的な記事などはこちらから見れます。

3日目

3日目の会場は、MGM Grandで参加しました。

朝食

相変わらずの甘そうなパンとフルーツに加えて、スクランブルエッグ、ベーコン、ソーセージなどが揃ってました。ベーコンはかりかりでした。

ランチ

本日のランチは中華っぽい感じでした。白いお米もあったので日本人的にも良かったです。

デザートもかなり充実してました

おやつ?

昼過ぎから、ピンチョスみたいなのやお菓子も会場に出てました。

ナイトパーティ

3日目は、AWS Japanが主催してくれた、日本人向けのClosedパーティーに参加しました。2日目は独り言以外で日本語を話さなかったので、かなり日本語話せました。 料理は、話しているウェイターさんが「一つどう?」って声かけてきてもらって食べるという形でした。

二次会

一次会近く地元の飲み屋街でお互い初対面同士で二次会しました。 お酒を1本買うと1本ついてくるという謎システムと、謎のAsada Friesをつまみに飲みました。

4日目

4日目の会場は、Mandalay bayで参加しました。

朝食

甘いパンが割りと控えめでした。その代わりジャムとかが大量にあるパターン。

ランチ

ランチは自分で作るホットドッグ。

そしてなぜかポテチも

re:Play

4日目の夜は、AWSが主催のクラブイベント。 ステージが3つあり、フードコートなども併設。飲んで踊っての大宴会でした。

5日目

最終日はVenetianにて参加しました。

朝食

安定の甘いパンとフルーツ。後はマフィンバーガー?的なのと、re:Partyでも出てたPupusaがありました。今回のre:Inventで初めて食べましたが、エルサルバドルやホンジュラスの郷土料理だそうです。

昼食

re:Inventは5日目の昼に終了なので、ランチは出ませんでした。なので個人でShake Shackに行ってきました。 バーガーのコンボと、赤ワイン頼みました。お酒を頼んでいるとはいえ、$30超えで日本円で5000円以上の贅沢ランチ。

カジノにて

昼のハンバーガーがお腹に残っていて、お腹減らなかったのでビールだけ。

負けました。

帰国

機内食

よくわからない料理でした。(ラスベガスで食べてたもの、大半名前分からず食べてはいましたがw)

さいごに

いかがでしたでしょうか?ひたすら食べたもの貼り続けただけのブログなのでなんじゃこりゃって感じかもしれませんが、真面目な記事も書いているのでぜひこちらからご覧ください。

現在、私たちと一緒に挑戦してくださるグルメなエンジニアを募集しています。記事など読んでご興味持たれた方おられたら、ぜひご応募ください。(グルメじゃなくてもご応募ください)

recruit.leverages.jp

AWS re:Invent 2023 グルメ紀行 前編

はじめに

レバレジーズ株式会社 テクノロジー戦略室室長の竹下です。技術的なことだけでなく、ゆるっとした内容もレポートしたいと思ったので、現地の食べ物をレポートしようと思います。AWS re:Inventでは開催期間の朝食、昼食が全部出て、夜もパーティーなどが開催されているため、イベントの料理を中心にご紹介していきます。

AWS re:Invent前日以前

まだ始まっていないので前日は自分で店などを探して食べに行きました

飛行機

2食出ました。Chicken or Beafを期待してましたが、Chicken or PastaとYakisoba or Omletでした。残念です。

Chicken

と、Yakisobaを選びました

ランチ

Outback Steakでランチしました。さすがステーキの国。超肉厚

おやつ?

食べられません(バスソルト)

晩酌

さて突然のクイズです。ビールとビーフジャーキーでいくらでしょう?

答えはこちら(選択反転で見れます) => 約3300円(22$)インフレと円安やばい

AWS re:Invent 1日目

朝食

アメリカンな感じで、甘いパンしか無い。。。ヨーグルトとフルーツもありました。

ランチ

ランチはメキシコ風でタコスなどがありました。デザートも有り、かなり満足度が高い。 会場はVenetianで食べましたが、昼食会場もめちゃくちゃ広かったです。

あと、Wynnではコーラなどのドリンクも置いてました

晩ごはん?

エキスポ(スポンサーブース)で様々な料理とお酒が食べ飲み放題でした。皆酒を片手にスポンサーブースを回ってました(もちろん私も)

2日目

朝食

朝食は、相変わらずフルーツと甘いパンが有りましたが、追加で数種類のソーセージだったり、ポテト炒めたものや、卵白を固めたなにかなどがありました(egg white frittataという料理かも?) 甘いもの以外が出たので食べごたえ有りました。

ランチ

2日目は、セッションの間があまり無かったのでサンドイッチのLanch Boxにしました。りんごが丸々1個入っているあたりすごくアメリカを感じました。

ナイトパーティー

夜はDatadogなど4社がスポンサードしているナイトパーティーにお邪魔しました。
料理に関して、ウェイターが机を回っててピンチョスみたいなのを「ひとつどう?」と進めてくる形でした。そのため、会話に夢中で食事の方は撮り逃してしまいました。すみません。(3日目ではちゃんと写真撮れたのでご容赦を。似た感じでした)
ちなみに、お酒でワインを頼むと、white/red以外にぶどうの品種の確認されます。「ピノ・ノワールだけどいい?」とか。日本だとぶどうの品種を聞かれることなんて無いので新鮮でした。

3日目~

AWS re:Invent 2023 グルメ紀行 後編に続きます。

最後に

来年は自分もAWS re:Inventに出て美味しいごはんを食べたい!という方は、ぜひ下のリンクからご応募ください。

recruit.leverages.jp

AWS re:Invent 2023 - LLMOps: The lifecycle of an LLM の(おそらく)世界最速レポート

はじめに

レバレジーズ株式会社 テクノロジー戦略室室長の竹下です。 現在 AWS re:Invent 2023に現地ラスベガスで参加しています。皆さんに少しでも早くラスベガスの風を感じてもらうために、月曜午前の”LLMOps: The lifecycle of an LLM”セッションのレポートを、あの会社や、あのブログより最速でお届けしたいと思います。

他の記事も見たい方はこちらの目次からお辿りください。

セッション概要

LLMOpsを進めるに当たって、E-mailのサマリーを自動で作成するシステムを例に出しながら、どのような観点でどのように意思決定をするかをシミュレーション。また、AWSのサービスをどのように組み合わせてシステムを実現できるかの構成の紹介もあり

セッションの内容

今回は、Toolingと、LLMOpsの構築プロセスについての話をしていく。 E-mailのサマリーを自動で行うシステムを例にして話をしていく。 LLMOpsにおいても、「Start small, think big」は大事。 まずは、ただサマリーを作る部分から始めるものの、最終的には各人のドメインを理解したシステムを考えて作る必要がある

MLOpsとLLMOpsまたFMOpsの違いはなにか? どちらもほぼオーバーラップしている

LLMOpsには、3タイプのユーザーがいる。 Provider: Tuners, Customer それぞれ必要なスキル、注目点が違っている

LLMOps構築までのプロセスと、構築後の改善プロセスがある。 まずは構築段階の話をしていく

まずはUseCaseの分析が必要。Criticality, Scale, Task Type, Eloquence, ROIの観点が大きく考えられる。今回のE-mailのサマリーシステムの場合は、 Criticality: Low 内容多少違っていたとしても、メールの本文を読めば良いので、優先度は低い Scale: Low 自分のメールの入力だけで良く、出力もそのユーザーに向けてだけなのでデータ的にスケール要件は低い Task Type: Specific メールの要約というSpecificな範囲 Eloquence: Medium 文章的に自然である必要はある程度ある ROI: 重要。生産性を高めることがちゃんと出来る必要がある

LLMモデルを選択するときの判断軸としては以下のような物がある。

この中でUseCaseで重要な項目と優先度を見積もっていく 今回のE-mailのサマリーシステムの場合は Cost > Precision > Speed となる。

また、通常のDeepLearningなどはハイパーパラメーターなどの調整となるが、LLM、GenAIの場合は、プロンプトの調整となる

モデルが決定し、調整も出来たら、評価が必要。 モデルは完璧では無いため多層的に、図のようなチーズモデルによって評価し、致命的な問題が無いかを適正にチェックする必要がある。

構築が完了したら、あとは改善のループを回す必要がある。最初の構築はS3がらSageMakerのNoteBookなどを利用し、BedRokSummaryを投げて結果を返す。

システム化する、受け取ったメールのデータを転送、バッチを定期実行、出力された結果をメールする、QuickSightにつなぎこんで評価を可視化するなどをするため、以下のような構成になる

更に進化させるには、Orchestrationも必要となってくる

最後に

現地時間 2023/11/27 12:01 書き上げました。セッション聞きながらリアルタイムでまとめてリリースしたので、きっと世界最速レポートになっていると思います。 聞き漏らしたところもあるので完璧な内容ではない部分もありますが、ご了承ください。

現在、私たちと一緒に挑戦してくださるエンジニアを募集しています。ご興味のある方はぜひ採用サイトをご覧ください!

AWS re:Invent 2023 レポートまとめ(随時更新)

AWS re:Invent 2023に弊社エンジニアが現地ラスベガスで参加しました。 セッションなどのレポート等を随時更新していきます。 こちらはそのレポートなどへのリンクのまとめ記事です。

技術記事

おもしろ記事

さいごに

現在、私たちと一緒に挑戦してくださるエンジニアを募集しています。SREの募集もありますので、記事など読んでご興味持たれた方おられたら、ぜひご応募ください。

recruit.leverages.jp