キャディでエンジニア採用を担当しております片渕です。
今回は、エンジニアの社内勉強会「STUDDi」にてプレゼンがありました一部の情報（2ネタほど）を、レポート形式でお伝えしたいと思います。
STUDDIは、エンジニア全員が持ち回りで発表機会があるものですが、入社してくる方も増えてきたこともあり
- まだ一度もスピーカーになっていない方（新しく入られた方）の発表する場として優先する
- 好きな技術について思う存分語ってOK
という方針でやっております。
データ分析コンペの紹介
今回はまず2022年2月8日に開催された社内勉強会、竹原からのプレゼン内容をまとめております。
データ分析コンペとは？
竹原： キャディ公開の求人票に記載がある歓迎スキルにもKaggleという言葉が出ていますが、データ分析のコンペを知らない人が多いと思うので、今回は参加したことがない人にどのような内容なのかを知ってもらうことを目的にご紹介していきます。
また、私がキャディに入社してからやってきた仕事が、コンペの内容にも近かったので、合わせて紹介していきます。
まずデータ分析コンペでは予測精度が高い機械学習モデルを開発しているものと考えてもらえると良いです。
ホストとなる企業などからコンペで解いてほしいタスクとデータが提供されて、参加者が分析したり検証して、予測モデルを開発して予測結果を提出します。
それらが随時採点されランキング（リーダーボード）が出ているので、結果を確認しながら予測モデルを２〜３ヶ月かけて磨き続けます。
コンペの上位者は賞金がもらえたり、結果に応じてランキングやTierが上がるのでゲーム的にも楽しいです。
なぜ私がデータ分析コンペを推すのか？？
竹原：
まず、先程お話したようにゲームのように楽しく取り組めるというのはあると思います。
また、学習のためのプラットフォームとしても魅力的です。
自分が担当している業務では扱わない様々なデータを手を動かしながら経験、試行錯誤することができます。また、コンペ期間中にプラットフォーム上のフォーラムで活発な議論や解法の共有がされており、技術的にも考え方的にも多くのことを学ぶことができます。
コンペの種類について
竹原：
データ分析コンペにも様々な種類のものがあるので、紹介します。
まず、データやタスクの種類、またモデルに課される制約も様々あります。データは一般的には表形式のような構造化データ、画像やテキストや音声のような非構造化データがあります。また、ECサイトの購買履歴、株のチャート、医療画像、スポーツの映像などもっともっとありますが、データのドメインも多岐に渡ります。
制約に関しても、機械学習モデルを作るときに、提供されたタスクやデータに合わせて、推論時間や提供したプラットフォームで動かなければいけない、外部データの利用の可否、など様々な制約条件もあります。また、推論時間が短いものには、特別な賞を与えたりするようなものもあります。
開催期間については、Kaggleなどの一般的なものは２〜３ヶ月です。ただ、期間も長いため期間中にフルコミットする必要はないです。参加者は並列して色んなコンペに参加したり、最後の１ヶ月だけ参加するなど色々な形で参加しています。また、コンペによっては短期間コンペのものもあります。1日以内に終了する超短期のものや、１〜２週間くらいの短期のものもあります。そのようなコンペは、どちらかというと期間中に新しい技術を学ぶというよりは、これまでやってきた経験や知識、技術をその場で試すようなイメージです。
参考文献: 「おすすめコンペは何？」の答え方を真面目に考える
キャディでの仕事 ≒ データ分析コンペ
竹原：
最後に、キャディでの業務もデータ分析コンペにも似た部分もありましたので簡単に紹介します。
最近、図面から図面に含まれる属性を予測する機械学習モデルの初期開発をしていました。
まず、そもそもタスクがどういうものかを理解して、また、社内で保有している図面解析ツールを動かしてみたり、図面を用いた過去の機械学習に関する取り組みを調査して、初期の方針やタスクのドキュメント化を進めました。このプロセスは、コンペでも提供されたタスクやデータを見てから、自分の方針を固め、関連する論文や過去のコンペを調査していく点にとても似ていました。
次に、実際に機械学習モデルに用いるデータセットを用意します。この際には、実際に運用で機能するように適切に学習データやオフライン検証用のテストデータを分割する必要があります。運用で利用する場面での精度が適切に検証できるように、書き方が異なるもの、ノイズの多いものなど性質の違う様々な図面を適切に用意する必要がありました。このプロセスも、コンペでのリーダーボードのスコアとローカルのスコアの相関があるようにデータを分割して分析、検証するプロセスに似ているなと思いました。
そして、用意したデータセットでベースラインとなるモデルを学習し、精度や誤検出結果を観察します。今回は初期の開発だったこともあり、以降の実験が効率的にしやすくなるようにパイプラインの整備をしていくことに力を入れたりなど、こちらもコンペの初期の取り組み方に似ている部分はありました。そして、コンペと同様に観察した精度や誤検出結果をもとに、次の実験や精度改善のためのアイデアを整理して、チームメンバーからのレビューを受け、継続的に改善に取り組みます。
このようにキャディの仕事とコンペの仕組みは近い部分があるので、キャディ内にもコンペのような皆で協調的にモデルを改善する仕組みやプラットフォームができたらいいなと思いました。また、面白いデータやタスクも多いので外部向けのコンペを開催できたら良いなとも思いました。
Microservicesについて
続いて2022年2月15日に開催された社内勉強会、刈部からのプレゼン内容をまとめております。
https://speakerdeck.com/caddi_eng/20220215-karibe-microserviceskohi
Microservicesとは何か？
刈部：
Microservicesとは、1つのアプリケーションを動かすために、小さなサービスの集合体を設計して開発するアプローチを指します。
正確な定義はなく、各社で採用して設計・提供しているのが実態です。
メリットとしては、サービスが分かれているのでデプロイしやすく、テクノロジースタックが分けてあるので適材適所で使え、チームを分けて開発ができるので組織的な柔軟性がある点ですね。
デメリットは、複雑になりやすいことです。
設計パターンとしては、API Gateway、Choreography、Microservice Chassis、Service Discoveryと４つあるので、順番にご説明していきます。
まずAPI Gatewayですが、これは外部からリクエストがあるとGatewayがすべて受け付け、Backendをたたいて1つのAPIとして提供するものです。
バックエンドの負荷が上がらないように流量制御したり、似たようなリクエストが来たらキャッシュで返したりすることも担いますが、パフォーマンスやスケーラビリティに課題を残します。
Choreographyは、非同期のメッセージによってサービス間で協調して1つのビジネス的操作を実現するものです。
メッセージブローカーが、クラインアントからの要求を関連するサービス系と処理を行うワークフローを実現するのですが、サービス数が増えると、複雑なピタゴラスイッチになってしまう懸念はあります。
Microservice Chassisは各サービス共通で必要な基盤を提供するもので、サービスの新規作成が早く簡単になるのが特徴。
Service Discoveryは、サービスのネットワークロケーションをクライアントがどうやって見つけるのか？という点についてです。
普段キャディではk8sを使用しているため、開発者はあまり意識する必要はありません。
実際の企業ではどのように使われているのか？
刈部：
例えばUberでは、プロダクトやプレゼンテーションのレイヤーで、各サービスでMicroserviceのような位置付けて持っており、API GatewayはEdgeレイヤーにてAPIを構成・提供している形になっています。
またNetflixでは、Orchestratorのパターンとして採用しています。これも非同期による設計パターンで、メッセージブローカーではなくサービスを置き一連の非同期処理を管理してあげるものです。
Wantedlyでは、Microserviceの開発ガバナンスを高めるために共通ライブラリを開発しています。まさにこれはMicroservice Chassisです。
Service Discoveryは、Netflixではeurekaを自作しています。
ここまでいくつか例をあげてきましたが、Micorserviceは名前の通り、どれも複数サービスを協調させて機能提供するものです。
複数のサービスを協調させて全体として1つの系を成すので、ソフトウェアの概念におさまるものではありません。
そこで次に、実社会ではどういう仕組みなのか？を例をあげてみたいと思います。
実社会ではどういう仕組みになるのか？
刈部：
こちらはファミレスの写真ですが、ここにもMicroserviceが隠れていると言えます。
スプーンやフォークは食器メーカーが作ったもので、食材もここのファミレスの会社が調達して料理しているだけですよね。水も水道局から、イスなどは家具メーカーから調達されています。
このように１つの料理をテーブルに並べるだけでも、バックエンドは様々なサービスを安く提供できることに集中していて、調達を得意な業者に任せています。
こうした社会的分業は、労働が専門化することで作り出されるものです。現実社会も専門性を組み合わせるものですよ、と考えることができますね。
キャディのビジネスモデルをMicroservicesの視点で見ると
キャディのビジネスモデルも同様で、発注者と加工会社の間にキャディがいて、API Gatewayで見たものと同じく内部構造を隠しているように見えてきますし、加工会社に発注して最終的には顧客に納品しています。
パターンについても、顧客から発注というリクエストに対して、複数の加工会社（サービス）に発注し、製品を納品する（レスポンスをする）プロセスとなります。
キャッシュについては、キャディで抱える在庫のようなものと考えることができ、顧客から似たような発注があれば、キャッシュから引き当てることでリードタイムを短縮できます。
Choreographとしても、メッセージを製品と置き換えることができそうで、キャディを介さず加工会社同士でサプライチェーンを構築ができる可能性があります。
ただ、サービスの数が増えると複雑さが増してピタゴラスイッチを組み立てることになるので、Netflixの取り組みを踏まえるとキャディもChoreographyよりもOrchestrationを採用した方が良さそうということも見えてきます。
Microservice Chassisについては、共通する機能を提供することで加工会社共通のプラットフォームに相当すると考えられます。
これは在庫情報や不可状況のObservabilityを上げることにもつながると考えています。
おわりに
今回は、2回分の社内勉強会の内容をまとめてみたのですが、いかがでしたでしょうか。
記事内容をご覧いただいて、興味持った方はこちらにて、お話する機会をご用意しておりますので、ぜひご活用ください。
また社外向けに一般公開するイベントに関する情報は、キャディのconnpassをご用意しておりますので、こちらもご登録いただけますと幸いです。
最後までお読みいただきまして、ありがとうございます。
