服好きデータエンジニアの就活事情

自己紹介

初めまして!2023年4月に新卒で入社した中村友哉です!

入社して早2ヶ月経ちましたが、早く仕事を覚えるためにがむしゃらに働いております。

この記事では、エンジニア就活のことや、エニグモに入社してどう感じたかお話しして行こうと思います。

エンジニアを目指したきっかけ

私がエンジニアを目指したきっかけは、小学校からの幼馴染です。

彼とは大学生になっても毎年会うような仲で、よくくだらない話で盛り上がっていました。しかし、大学3年生になると急に意識が高くなっており、別人のようでした。話を聞くとエンジニアを目指すようになってから考え方・行動力を意識して変えていったとのこと。

将来の理想的なキャリアを想像し、そこから逆算して今何をすべきか考え実行する、そんな彼の行動・姿勢に感銘を受け、彼のように自分の考えを持った人間になりたいと思いエンジニアという職業に興味を持ち始めました。

そこから、とりあえず勢いに任せてPythonの入門書を買ってプログラミングの勉強を始めました。意外と新しいことをやってみるのは楽しく、競技プログラミングアルゴリズムの勉強もするようになりました。

学部時代はプログラミングの授業があり、情報系の知識に触れる機会がありましたが、当時は苦手意識を持っており、まさか自分がエンジニアを志すとは夢にも思いませんでした。

エンジニアになるためにやったこと

大学院に進学するタイミングで就活をスタートしましたが、IT業界・エンジニア種類などの知識が皆無だったことから、どんなエンジニアになりたいか考えるところからスタートしました。

試行錯誤

まずはPythonをやっていたこともありデータ周りの技術を学びましたが、途中フロントやバックエンドの技術も学び、現状のスキルのみで自身の適正を判断しないよう心がけました。

この時点では確信は持てなかったものの、データ周りの技術に興味が湧き、データサイエンティストを目指すようになりました。大学院の専攻は電子工学というソフトウェアと真逆のものでしたが、指導員の方と相談して機械学習を取り入れた研究ができることになり嬉しかった思い出があります。

それからは、統計学・データ分析をはじめとし、SIGNATEというデータ分析コンペなどで機械学習モデルの勉強に取り組みました。

方向性の決定

データサイエンスを学んでいくにつれデータを用意するところが難しいことを知り、その泥臭い作業を担当するデータエンジニアという職種があることを認識しました。

確かに個人レベルで扱うようなデータは綺麗なものが多く、整形せずとも使えることが多かったので気にしていませんでしたが、企業が扱うようなビッグデータは扱える形にするには多くの苦労を伴うだろうと想像できました。

そこで、ビジネスの世界でどのようなデータが扱われ、どんな苦労が発生するのか知りたいと思い、修士一年の12月から東京のとある企業でデータサイエンティストとしてインターンを始めました。

インターン経験

インターンでは以下のように幅広い技術を経験させていただきました。

  • データ分析基盤の開発・運用
  • BIツールの整備・ビジネスサイドへの展開
  • 自然言語処理
  • NLPモデルのPoC・プロダクト応用
  • MLOps
  • プロンプトエンジニアリング

その中でも、私が特に興味を持ったのはデータ分析基盤の開発業務でした。というのも、データを活用しようにもデータを活用できる環境がないことには何も始まらないので、非常に重要な領域だと感じたからです。

そのような基盤作りに携わり、社内の関係者・ビジネスに貢献していきたいと思い、データエンジニアになることを軸に就職活動に臨みました。

ポートフォリオの作成

就職活動に望むにあたって、自分のやりたいこと・技術スタック・課題解決能力などを伝えるためにポートフォリオの作成も行いました。

私は当時フットサル部に所属しており、我が部のコミュニケーションにおける課題を解決するために部活仲間と協力し、LINEbotを作成しました。ユーザーの要求を満たすことを最優先に考え、できるだけフラットな視点で技術選定を行ったり、私が卒業した後のことも見据え、運用しやすい構成にするなどの工夫を凝らしました。

この開発経験は、データエンジニアとしての技術を伸ばすというよりも、エンジニアとして課題を解決する際の思考・取り組み方を改めて考える良い機会となりました。

就職活動〜入社

修士一年の1月くらいから本格的に就職活動をスタートしました。

ドメインにこだわりはありませんでしたが、昔から服が好きだったので、できればアパレル系のデータを扱える企業で働きたいという願望がありました。しかし、アパレル系の事業会社でエンジニアを募集しているところはそもそも母数が少ないので、探すだけでも一苦労でした。

そんな中、自分の好きなインポート系のブランドを扱いつつエンジニアを募集しているエニグモを見つけました。エニグモのことを調べていくうちに、「ここしかない!」と思いすぐに応募しました。

一次面接から早速データエンジニア・マネージャーの方とお話しすることができ、自分のやりたいこと、エニグモの目指しているところを早い段階で擦り合わせることができました。個人的な野望として、ブランドの情報を集めて最新のファッション動向を知れるようなプラットフォームを作りたいと思っており、そのような考えに共感してくださり、現場のエンジニアの方と意気投合したことを覚えています。

この時点で、ご縁があったら絶対にエニグモで働きたいと思っていたので、続く二次面接・最終面接では他のチームの業務や、社長の目指しているところを把握することを主眼において面接に臨みました。

面接を担当していただいた方々は全員優しく、素の自分を受け入れてもらったことが印象的でした。内定後も人事の方と何回か面談する機会を設けていただき、不安要素が全くない状態で入社することができました。

入社して2ヶ月経ち感じること

入社後、データ・機械学習・検索の基盤開発・運用を行うデータテクノロジーグループに配属されました。具体的な業務としては、データエンジニアとしてデータ分析基盤の開発・運用を担当し、他部署からのニーズに応えるため日々データ周りの整備を行います。

入社して一ヶ月くらいは単語レベルでわからないことが多く、いわゆるパニックゾーンに入っていました。特に、現状把握する上でドキュメント等が完全に整っている訳ではないので、現場のエンジニアが前提として備えている技術・知識をキャッチアップするのに苦労しました。

しかし、困っているときは、一人でデータエンジニアを務めてきたメンターの方や、エニグモでのエンジニア歴が長く、開発背景を熟知しているマネージャーの方が親身に相談に乗ってくださるので、滞りなく業務することができました。

二ヶ月経った今、まだ周りの方々の手助けなしではタスクを完遂できないので、早くチームの方々、会社に貢献できるような人材になるべく、多くの経験を積んでいきたいと思っています。

今後の抱負

まずは、一人で滞りなく業務を遂行できるようになることを目標にしています。

大きな目標としては、データドリブンな意思決定ができる環境をさらに整え、データの民主化を目指していきたいと考えています。

入社式で社長から激励のお言葉をいただき、その中でも「コンフォートゾーンに逃げない」という言葉が胸に刺さりました。その言葉を信条に、日々業務に取り組んでいきたいです。

最後に

この記事を見て、エンジニア就活に役立ててくださる方がいらっしゃれば幸いです。

データエンジニアは地味なイメージを持たれる方が多いと思いますが、ファッションデータを扱える弊社は、服好きにとっては楽園のような環境だと思います。

とは言っても、弊社はファッションにそこまで興味があるわけではないエンジニアも多いです。ファッションに興味がないけどデータエンジニアを志す方にとっては、分析基盤の拡大フェーズを経験できるという点でとても魅力的な環境だと思います!

ざっくばらんな話になってしまいましたが、最後までお読みいただきありがとうございました!

RubyKaigi 2023に参加しました!<前編>

こんにちは。サービスエンジニアリング本部の寺田と橋野です。

RubyKaigi 2023にenigmoから2名、現地の参加をしました。

今年のRubyKaigi 2023は2023年5月11日〜5月13日に長野県松本市まつもと市民芸術館で開催されました。
去年と大きく違うところは、公式パーティーやスポンサー企業によるドリンクアップの企画があったところです。
去年より多くのRubyistとの交流ができるようになりました!

本ブログは、前編と後編に分けてお届けします。

1日目

今年は夜にOfficial PartyがHotel Buena Vistaで開催されました。 たくさんのドリンクやフードが用意されており、立食形式でおこなわれ、自由に参加者と交流することができました。
参加者の中には知り合いの知り合いに出会えたりして、エンジニアの輪はつながっていることを実感することができました。

Official Party後には、Findyさんによるドリンクアップの企画がありました。 そこでは、去年RubyKaigiで知り合った方達と再開することができ、楽しい時間を過ごすことができました。 また、お店もドライフラワーがたくさん飾ってあってとてもおしゃれでした!

2日目

2日目にはスタンプラリーがおこなわれていました。 対象の企業ブースを巡り、スタンプを全て集めるとピンバッチをもらえます! ピンバッチは複数種類があり、どれも魅力的でした。

シールだったりスタンプだったり✨

夜には、スポンサー企業さんがドリンクアップの企画が複数ありました。
橋野はライザップさんのドリンクアップに参加させていただき、馬肉を食べながら、Rubyistと交流しました。 参加者の中にMatzさんもいて、色々とお話を聞くことができました。

3日目

RubyKaigi終了後には、アフターパーティーが開催されました。
また、夜にはRubyMusicMixinも開催されていました。
(私たちは不参加だったため、写真や感想はありません!!😭)

今年は色々な企画やイベントがあり、たくさんのRubyistと交流することができました。

観光

観光名所へ行ったり等はなかったのですが、名物であるそばを食べました!
受付時に貰える3000円分のバウチャーチケットがあるのでそちらを使用しました。 駅周りにはたくさんの飲食店があり、ご飯に困ることはありませんでした。
珈琲屋さんや喫茶店などの魅力的なお店がたくさんありました。

しゃぶしゃぶも食べました

感想

  • 私にとっては初めての RubyKaigi でした。技術カンファレンスとして多くの最先端の研究に触れられたことはもちろんのこと、何より Ruby コミュニティのことが大好きになれた3日間だったなあと思います。パーティーでは普段からお世話になっている Ruby や Gem のコミッターと出会い、貴重なお話しを聞くことができました。さらにここで出会ったコミッターの方とその後も一緒にオープンソースのプロジェクトに参加させてもらえるようになったりと、自身と Ruby との関わりを一気に近づけてくれました。スポンサーブースではさまざまな企業の方々とお話しをして、同じく Ruby を使って Web アプリケーションを作る仲間としてさまざまな苦悩を共有したり、これはいいなというアイデアを得たりと多くの学びがありました。名刺も交換させていただき、仕事の面でのつながりも作れました。(寺田)

  • 去年参加したRubyKaigi 2022での反省をいかして、気になる発表の情報を事前に調べるようにしたり、事前イベントに参加したりしました。
    その結果、去年より話の内容がわかるところが増えたので、用意をしてから参加をしてよかったです!
    今年も同世代のエンジニアの方との交流ができたり、また、女性エンジニアの方と知り合うことができました。同じ悩みを共有したり、キャリアについて色々教えていただいたりして技術以外のことも新たな発見をすることができました。
    3日間、発表を聞いたり、コミッターさんたちの話を聞くにつれて、Rubyのことをもっと知っていきたいという新しい気持ちが芽生えました。Rubyのしくみを購入したので読み進めたいと思います。
    長野県には初めて訪れたのですが、とてもいい場所だったので、次は観光しに行きたいです!(橋野)

後編は印象に残ったセッションの紹介をしていきます!
お楽しみに!


株式会社エニグモ すべての求人一覧

hrmos.co

AWS Summit Tokyo 2023 に行ってきました!

こんにちは。 株式会社エニグモ 新卒 2 年目 エンジニアの橋野です。

先月開催された、AWS Summit Tokyo 2023 に行ってきました。 今年の AWS Summitはハイブリット開催で、オンライン、オフライン共に参加できるようになっていました。 会場での開催は、2019年以来の4年ぶりということです!

私は、現地で1日目のみ参加させていただきました!会場は、千葉県の幕張メッセです。

AWS については初心者ですが、初心者でも楽しめるということで行ってみました!

サミットでの過ごし方

時間 行程
10:00~ 受付 朝昼兼用ごはん
11:00~ スポンサーブース
12:00~ これから始める AWS クラウド、最初の一歩は AWS Cloud Essentials
13:00~ AWSome Day ~踏み出そう、AWS への最初の一歩~
16:00~ ニンテンドーアカウント リノベーションプロジェクト
17:00~ AWS AI サービスを使ってあなたのシステムにも機械学習を導入しよう!

幕張メッセの会場について、すぐに受付を行いました。事前に受講票を印刷していたので、スムーズに会場内に入ることができました。

スポンサーブースでは、企業からノベルティをもらうと受講票をスキャンするという仕組みは新しくて面白かったです。
また、AWS 社員から直接話を聞けたり、スポンサーの導入事例やスポンサーのサービスを詳しく聴くこともできました。

午後からは予約していたセッションに参加しました。
わたしは業務で AWS を担当していないので、初心者向けのセッションに参加しました。

私が参加したセッションはほとんどがサイレントセッションでした。発表者のマイクの音を手元のレシーバのチャンネルを設定することによって、聴くことができます。新しい!!

この取り組みは、没入感があって受講者としては非常に体験が良かったです。ただ、座席が取れないと立ち見できないので、早めにお席を確保しておきましょう!
今年は、事前にセッション予約をしていても、5分前くらいまでに入場しておかないと、予約していない方でも入場することができるようになるようでした。(私が見た限りでは)

ちなみに、椅子はパイプ椅子なので長時間のセッションを受講するとお尻が痛くなるので、ノベルティのクッションがあってよかったです。

印象に残ったセッションの感想

AWS Cloud EssentialsとAWSome Day

AWS Cloud EssentialsとAWSome Dayは、AWSクラウドをこれから利用する方にとって非常に役立つプログラムでした。 この2つのプログラムを受講すれば、AWSに多様なサービスについて、どのようなことが実現できるのかということを理解することができるようになっています。

AWS Cloud Essentialsは、AWS の基本的なサービスの紹介でした。具体的には、「リージョンとAZ」「EC2」「RDS」「VPC」「責任共有モデル」について理解することができます。
話のテンポがゆっくりで聞き取りやすく、集中して受講できるようなセッションでした。

AWSome Dayの方は、AWS Cloud Essentialsよりもより、多様なAWSの主要なサービスについて、理解することができるプログラムです。
AWS Cloud Essentialsの内容に加えて、「IoTサービス」「機械学習」「ブロックチェーン」などについての説明を受けることができました。聞いたことがないサービスなどもたくさんあったので、ワクワクしながら受講することができました。
講演後には、AWSのエキスパートの方と直接話すことができるので、質問や疑問点を解消することができます。現地参加ならではの魅力です!

以上のように、AWS Cloud EssentialsとAWSome Dayを受講することで、AWSの主要なサービスについて知ることができました!
この2つを受講することによって、より理解が進むことができました。

たとえば、ストレージでは、S3やEFS、EBSという3つのサービスが紹介されていました。私はファイルの管理にはS3を使っていますが、他の2つのサービスについては知りませんでした。
S3は非常に便利ですが、ファイルを直接マウントしたい場合や、より高速なスループットが求められるワークロードでは、EBSやEFSの利用も検討できると思いました。
リレーショナルデータベースでは、Amazon RDSと、Amazon Auroraというサービスが紹介されていました。私はアプリケーション開発をしているので、SQLクエリを通じてデータベースとのやり取りをしますが、そのインフラがAWSやオンプレミスのサーバー上でどのように動作しているのかについてはあまり考えたことがありませんでした。
この講演を聞き、Amazon Auroraというデータベースを使うことで、高い障害耐性やデータ耐久性を提供していると知りました。 Auroraを利用することでDBの運用が楽になると思いました。
これからAWSを学びたいという方は、来年のSummitで、AWSをより深く理解するための第一歩として受講することをおすすめします!

ニンテンドーアカウントリノベーションプロジェクト

次に受講したセッションは、「ニンテンドーアカウントリノベーションプロジェクト」という 任天堂株式会社と株式会社ディー・エヌ・エーのセッションです。
このセッションでは、ニンテンドーアカウントというNintendo Switchなどでゲームをする際に利用するユーザーアカウントシステムにおけるリノベーション案件をどう進めたかのセッションでした。 元々はEC2 + Perl で構成されたシステムで、そのリノベーションを実施する理由としては、いくつか挙げられていましたが、さらなる利用者の増加に伴って、現状の技術スタックでのサービスレベルの維持が困難と判断したことと集約できそうでした。

リノベーションは、アプリケーションを全面的にPerlからJavaに書き換え、インフラをコンテナに置き換えていき、アーキテクチャをマイクロサービスにしていくという内容です。
多くの企業が採用しているモダンなアーキテクチャや言語の採用というような一般的な内容に見えます。
実際に移行を進める上で、莫大なPerlのコードを全てJavaに書き換えるのはかなりの労力です。 そこで、ニンテンドーでは、一時的に人員を増加させるためのリノベーションチームを発足しました。ここが、私がこの登壇で一番興味深いと思った点です。
このチームはリノベーションが完了された段階で、解体されることを目標に作られたチームで、リノベーションプロジェクトを推進する責務を担っています。
サービスレベルについての責務を持っているチームと独立したチームを作ることによって、保守的にならずプロジェクトを進めることができるという側面があると思いました。
もし、同じチームにしてしまったら、目先のサービスレベルの方が重要になるため、なかなか進まなかったのではないかと思います。

普段使っているサービスのシステムについて知ることができて大変興味深かったです。

参加を通して

AWS クラウドについて初めて学ぶことができ、非常に勉強になりました。
AWSの基礎知識や主要なサービスについての説明や、それらを活用するメリットや具体的な活用例など、わかりやすく解説していただき、初心者でもとても楽しめました!
AWSクラウドの無料枠の紹介があったので、個人の開発でも利用してみようと思いました。
セッション登録の際にレベルが記載されているので、自分に合ったレベルのセッションを登録することで、楽しめると思います!
また、企業ブースでは、たくさんの展示や AWS の事例紹介があるので、余裕のあるスケジュールを組むとより楽しめそうです。

エニグモでも AWS を利用しています!

株式会社エニグモ すべての求人一覧

hrmos.co

Solr Operatorを利用したKubernetes上での検索システムの構築について

エンジニアの竹田です。
BUYMAの検索システムやMLOps基盤の開発・運用を担当しております。

今回はSolr Operatorによる検索システム構築を行いましたので、その実施内容と得られた知見についてご紹介したいと思います。

はじめに

昨期から今期にかけて、オンプレミスのシステムからの脱却、およびマイクロサービス化を目指し、商品検索システムのリプレイスを進めていました。
エニグモでは機能毎にApache Solrを用いた複数の検索システムを保持しており、クラウド移行に伴い、構築面や運用面の負担は大幅に軽減できております。

なお、リプレイスを行った商品検索システムの構成も下記の記事と大きくは変わっていません。 tech.enigmo.co.jp

今回フォーカスする検索システムの課題

検索システムの運用には、開発案件や障害対応、システムのバージョンアップやシステム増強作業などがあります。
中でも開発案件は、本番と同等のデータを利用したシステムにて検索の並び順や検索ヒット内容の検証が必要となる場合があります。

今まではオンプレミス環境にそのシステムを構築していましたが、今回の商品検索のクラウド移行に合わせ、同環境をクラウド上に構築することになりました。

システムのライフサイクルが短いため、より簡素に構築・廃棄を行えるようにしたいという課題があり、そこで案として出たのがSolr Operatorの利用です。
結果次第ではサービス運用でも利用できる可能性も考慮してSolr Operatorを利用した構築の検証を行いました。

なお、本記事ではある程度KubernetesApache Solrのことをご存知の方を対象としている点をご容赦ください。

Solr Operatorについて

Welcome - Apache Solr Operator
Solr OperatorはKubernetesのCRD(Custom Resource Definition)として提供されているもので、SolrCloudやZookeeperClusterといったkindによりSolrシステムを一元管理するイメージという理解で良いかと思います。 2023/04/24にv0.7.0がリリースされています。

Solr Operatorの概要や簡素な構築方法については、Google CloudのShimojo様が非常に分かりやすいブログ記事を公開されていますので是非ご参考にしてみてください。

  • Solr Operator を利用して SolrCloud クラスタを GKE Autopilot に構築する (前編) zenn.dev

  • Solr Operator を利用して SolrCloud クラスタを GKE Autopilot に構築する (後編) zenn.dev

構築時の簡単な構成は、以下のようになっています。
Zookeeper Operatorについては特に触る必要がなかったため、本記事では触れていません。

構成図

Solr Operator CRDの各リソース項目について

Solr OperatorはCustom Resource Definition(CRD)として提供されており、項目に合わせて定義を埋めていく形になります。
構成管理を考えた場合、helm installでSolrCloudクラスタを構築する際に適宜パラメータとして指定するよりも、Kubernetesマニフェストとして管理するのが望ましいと思われます。 ※helm installではなく、マニフェストを作成してkubectl apply -f <作成したマニフェストのyamlファイル>で構築する方式

以下に、kind: SolrCloudにおいて利用頻度が高いと見込まれるパラメータを列挙してみました。

spec配下の設定項目 内容 備考
solrImage 利用するsolrのコンテナイメージを指定 独自ビルドしたイメージも指定可能
solrOpts solr起動時のパラメータを指定
solrJavaMem javaのヒープサイズを指定
solrAddressability solrの解放ポートや外部接続定義を指定
solrGCTune GarbageColleciton用のチューニングパラメータを指定
customSolrKubeOptions solrのカスタム項目を指定 (※1)
updateStrategy solrの更新方式をを指定 未指定時のデフォルトがrollingUpdateのため注意
dataStorage solrのデータ格納先ストレージ persistentにして永続ディスクを利用
replicas solr podのレプリカ数

(※1) 以下、customSolrKubeOptions配下の項目

spec.customSolrKubeOptions配下の設定項目 内容 備考
ingressOptions 外部にingressを利用している場合に利用 annotationsでBackendConfigを指定するなどで利用
configMapOptions providedConfigMapにカスタムConfigMapを指定 solr.xmllog4j2.xmlを定義できる
podOptions solr podに対するオプション項目 (※2)

(※2) 以下、podOptions配下の項目

spec.customSolrKubeOptions.podOptions配下の設定項目 内容 備考
resources CPUやメモリのlimits/requestsを設定
livenessProbe Solrが動作しているかどうか 指定しないとhealthcheckが通らず、podが起動しない
readinessProbe Solrがトラフィックを受けられるかどうか 指定しないとhealthcheckが通らず、podが起動しない
initContainers Solr PodのinitContainersを定義できる
sidecarContainers Solr Podに設置するサイドカーコンテナを定義できる

あくまでサンプルですが、以下のようなマニフェストになるかと思います。

apiVersion: solr.apache.org/v1beta1
kind: SolrCloud
metadata:
  name: example
  namespace: solr
spec:
  replicas: 3
  solrImage:
    tag: 9.2.1
    pullPolicy: IfNotPresent
  solrGCTune: -XX:NewRatio=3 -XX:SurvivorRatio=4
  solrJavaMem: -Xms2048M -Xmx2048M
  solrAddressability:
    commonServicePort: 8983
  updateStrategy:
    method: StatefulSet
  dataStorage:
    persistent:
      pvcTemplate:
        spec:
          resources:
            requests:
              storage: 100Gi
      reclaimPolicy: Retain
  customSolrKubeOptions:
    configMapOptions:
      providedConfigMap: solr-config-map # configMapは先に作成・適用しておく必要がある
    ingressOptions:
      annotations:
        cloud.google.com/backend-config: '{"ports": {"8983":"solrcloud-backend-config"}}'
        cloud.google.com/neg: '{"ingress": true}'
    podOptions:
      resources:
        limits:
          cpu: 2
          memory: 6Gi
        requests:
          cpu: 2
          memory: 6Gi
      livenessProbe:
        initialDelaySeconds: 30
        periodSeconds: 10
        httpGet:
          scheme: HTTP
          path: /solr/admin/info/health
          port: 8983
      readinessProbe:
        initialDelaySeconds: 15
        periodSeconds: 5
        httpGet:
          scheme: HTTP
          path: /solr/admin/info/health
          port: 8983

補足となりますが、Solrが起動しない場合は、概ね以下の方法で原因を特定できます。

  • Solr Podをkubectl describeで確認
    kubectl describe pod example-solrcloud-0 -n solr
  • solr-operator Podをkubectl logsで確認
    kubectl logs solr-operator-xxxxxxxxxx-xxxx -n solr

マニフェスト適用後は、solrスキーマ定義やsolrconfig.xmlの配置、コレクションの作成と進めて検索できる状態にします。
こちらの作業についての手順は割愛します。

Solr起動後の管理画面等への接続については、上記で図示した通りingress経由としました。

実際に構築してみた所感

まだ検証段階ではありますが、以下の恩恵を得られるものと思います。

  • Zookeeperを特に意識しなくて良い
  • ディレクトリ構成も基本的には意識しなくて良い
    • SolrCloudを構築する上でのSolrの学習コストが下がる
  • マニフェストさえ用意しておけばSolrCloudシステムの作成、削除がkubectlコマンド一発で完遂する
    • CRDの項目が充実しており、かなり細かい点まで定義可能

苦労した点としては以下になります。

  • マニファストの設定誤りや漏れがあると結構ハマる
    • 特にヘルスチェック、リソース定義周りの定義誤りは何が問題なのか分かり辛い
  • CRDはかなり長大なマニフェストのため読み解くのが大変
  • 日本語での参考文献がほとんどない

運用利用に当たっては以下の項目を意識・検討する必要があることも分かりました。

  • Solr Operatorで構築できるのはSolrのインフラ面のみ
    • Solrのスキーマ定義や構成ファイルの配置はconfigsets APIzkCliコマンドを利用する必要がある
  • アクセス周りのセキュリティを気にしておく必要がある
  • 監視関連の定義は別途検討の必要がある
    • エニグモでは検索システムの監視にDatadogを利用しているため、対応方法を調査・検討する必要あり
    • Solr Prometheus Exporterを利用する方法もある
  • 用途の異なる検索システムを1つのSolrCloud kindに集約しない方が良いかもしれない
    • Solr Podの名称がprefix固定の連番suffix(例: xxx-solrcloud-1xxx-solrcloud-2)での管理となるため、Pod名称から用途が判別し辛い
  • 実サービスでの利用はAutopilotクラスタよりStandardクラスタの方が良いかもしれない
    • オートスケールに時間を要するため、ある程度リソースが確保された状態でないと運用は難しそう
  • Solr Operator自体のバージョンアップへの追従

また、合わせてSolr構成も見直した方が良いと感じました。

  • NRTや全TLOGのレプリカタイプでコレクションを作成した方が良い
    • 1podがダウンしても更新や検索に影響のないシステム構成にする必要あり
    • 必然的にDataImportHandlerのようにデータをpullする方式の採用は難しくなる

検証用途には手順を圧縮できるため便利に感じる一方、サービス運用には検討すべきことが多いという印象でした。
業務等でSolr Operatorの利用を検討されているようでしたら、本記事が一助になれば幸いです。

最後に

弊社では、本記事に記載したような新しい取り組みや、より良いシステムを作りを一緒に進めていくためのメンバーを随時募集しています!

株式会社エニグモ すべての求人一覧

hrmos.co

世界のリーダーシップが考えるAIへのアプローチとは?ジャマイカで開催されたカンファレンスレポート

BUYMA Globalの事業統括責任者をしているHibaruです。 私はエンジニアではないのですが、プロダクトマネージメント業務にも携わっており、今回は私がBUYMA Globalのプラットフォームに導入したAI企業「Mad Street Den(以下MSD)」が開催したカンファレンスに招待いただき、たくさんのインスピレーションを得ることができたので、ブログを書かせていただきます。

Montego Bay, Jamaica

カンファレンスが行われたのは、なんとカリブ海にあるジャマイカ

私は普段ロサンゼルス在住なのですが、ジャマイカは初上陸でした。 今回は開催企業の取引先で米国企業を中心に世界中からリーダーシップが招待され、ケーススタディや新しい技術へのアプローチ方法などをディスカッションする2日間のイベントでした。

DAY 1: Dinner / Meet & Greet

美しいカリブ海に浮かぶジャマイカのMontego Bayにあるリゾートに全員宿泊し、そこからバスで歴史的なハウスミュージアムであるローズホール・ゲストハウスへ。

Rose Hall Guest House

REBUILDと題されたイベントは今回で3回目の開催だそうで、初回はインド(MSDはインドが本拠地です)、2回目がドバイだったそうです。 REBUILDは単なるイベントではなく、「コミュニティ」だと開催にこめた思いなどがMSDのCEOとCTOから語られました。

“テクノロジーのトレンドは、ユーザーのインフルエンス力が大きなパワーとスピードをもたらす”

DinnerのKeynoteスピーチは、元P&GでGlobalのITチーフをしていたAndy Walter氏が務め、レガシー的な大きな組織に「インターネット」を導入した際のお話や、彼のキャリアでは常に「もっと社内の人にインフルエンスしなさい」と言われ続けてきたストーリーを話してくれました。

それから、Chat GPTの話にもなりましたが参加者たちの意見ではGoogleがいずれovertakeするだろうとの見解。 この大きなトレンドには、業界のインフルエンサーたちが大きく貢献しているという例でした。

Dinner

Dinnerでは海外のビジネスシーンでは欠かせないネットワーキングで、お互いのビジネスやチャレンジ、コラボレーションの可能性などを話します。(これがいまだに苦手ですが頑張りました)

アフリカ向けにブティック連携したマーケットプレイスを展開している会社や、中南米Amazonと呼ばれるマーケットプレイスなどEcommerceに関わる企業や、メディカル、ファイナンスなど様々な業界から、CEOやCTO、プロダクトマネジャーが参加していました。

Day 2: Case Studies & Panel Discussion

2日目はカンファレンス本番で、会場をHalf Moon Resortに移し、朝から夕方までケーススタディやパネルディスカッションが行われました。(ちなみにこのHalf Moon Resortは、エリザベス女王を始め多くのロイヤルファミリーが宿泊したそう!)

データセントリック vs モデルセントリック?

世界のCIO, CDTO, CDO, CEOが回答した答えはクリアだった

Data centric AI approach

  • AIにフォーカスする市場での答えは「データセントリック
  • CDOとCIOは、20-21年にAIに$50Bを費やしたが、ビジネスの成果という点では、何の成果も得られていない(*MITSloan)
  • 機械学習やAIの技術者・担当者は、「モデル構築」することにフォーカスしがち。しかし正解は「データのクリーンアップ、コネクト&アクティベーション」である(モデル構築が答えではない)
全ての基盤となる「データ」

Data is everything

MSDが考えるAIアプローチ・AI Transformationの始まりは、全てデータから始まる。 データがクリーンでない、統合されていない、正しいデータソースを見極められない、これらができていないと、結果としてコストが高くなり(データサイエンティストやマニュアル作業の時間的コストも含める)ROIが見合わなくなり、エンドレスにモデル構築をしなければならない。

“これまでの「AI Transformation」から「ROI-Driven AI Transformation」へ”

ケーススタディから学ぶAIアプローチ

  • AYA Healthcare: San Diego発のトラベルナース派遣サービス。Pandemicで急激に増えたトラベルナースのアサインメントのマッチングをするため、リアルタイムで対応できるAIレコメンデーションを使用。 ナースのプロフィールやスキル・資格とアサインメントが合っているか、お給料の希望レンジや希望ロケーションなど、そして特別なアサインメントには条件がクリアできるナースが登録している中から2名とかしかいない場合もあるので、そういった急務な案件をそのナースの検索結果のトップに出せるようにした。 今後はDocumentationスキャンのAutomationを導入しようと思っている。ナース登録やアサインメントに入る際のAgreement、書類のアップロードなどがスムーズにできるようにする

  • Fedex: Fedex x ShopRunnerのFulfillment OptimizationにAI活用。 特に荷物がどこのロケーションにあり、どこへ送るのか、またカスタマーが希望している優先順位は何か(配送の速さ、Sustainability、価格)によって配送オプションの出しわけをできるようにした。今後Cross-border向けのDocumentationスキャンもAI導入予定

  • PICARD: ドイツ発の老舗バッグブランド。PandemicをきっかけにOnline Storeに力を入れることになったが、モデル着用画像がなくEcommerceパフォーマンスは低迷。MSDの提供するVue.aiモデル着用AIを利用し、CVR +65%、AOV +12%、返品率 22%ダウンを実現させた。

Retail業界をAIがどう変えていく!?

実はこのテーマのパネルディスカッションに私も登壇させていただきました。 英語で世界のリーダーたちとゲストの前で登壇をするのはとても緊張しましたが、前もってかなり練習をしていったので、スムーズに発言できたのではないかと思います。 終わった後にたくさん皆さんに声をかけていただき、またBUYMAのサービスにもとても興味をもっていただけました!

  • 消費者の検索動向トレンドに合わせてAIを活用していくケースやユースケースが出てきている
  • AIを導入することでパーソナライゼーションやレコメンデーションが大幅進化している!例えば同じアカウントを使って違う家族のメンバーがお買い物をしようとしていたら?アクセスする時間帯と傾向をマシンラーニングし、そこでパーソナライゼーションやレコメンデーションを出し分ける例まであるそう。
  • 過剰在庫の世界的問題にAIがどう貢献できるのか?この過剰在庫という問題は環境やエコノミーにも非常に大きく影響している世界的問題。AIを使って、過剰在庫になる前にそれらの商品を予測し、プロモーションをしたり、追加発注をしないようにできる技術も開発されている。

Innovation x Leadership(AIや新しい技術へのアプローチ、組織改革へのアプローチ)

  • Victoria's Secret:

どのようにDigital innovationをLegacy化した大きな組織に素早く導入するか。 Story-tellingできるプロトタイプを作ることが重要。 50つのアイディアがあっても、そこから検討テーブルに上がるのが7-8つだったそう。 PassionがInnovationを作っていくこと、社内で新しいInnovationやアイディアをインフルエンスしていくことが重要だとここでも語れました。 そしてGen-z世代はTechnologyと共に生きているので必要不可欠であることを理解する。

中南米Amazonと呼ばれる大規模なマーケットプレイス。 ビジネス拡大が加速し、1000人未満だったエンジニアが数年で15000人のエンジニア組織に急速拡大。 大きな技術・組織改革において、「Culture / Language / Technology」を素早く共有し、適応してもらうにはかなりのチャレンジがあった。 10000人以上にNew Hireのうち、なんと70%がRefarralで構成されていることで、「Culture / Language / Technology」の適応の大部分をカバー、30%は全くの未経験も含んでいたが、この3割にはトレーニングに注力した。

たくさんの学びがありましたが、Key Takeawayをまとめてみます。

★基盤となるデータの重要性

★TechnologyはCultureであること(技術そのものが人の役割をTake overするのではなく、技術を理解しどのように扱う・活用するか考える人が重要である)

★TechnologyはCommunityであること(今回のイベントのように、様々な業界から人が集まりケーススタディやUse caseをシェアし、課題を共有し、アイディアを出せること)

2日目はカンファレンス後、プライベートアイランドでサンセットを見ながらのパーティー。 こんな規模でイベントを開催するMSDにとても驚き感心しました!

そして何よりMSDのCEOはインド人の女性で、テクノロジー業界で成功する女性としてインスピレーションをもらい勇気づけられました!

Bonding with girls in tech!

エンジニアではない私の体験&感想を書かせていただきましたが、いかがでしたでしょうか?

次回はぜひ社内のデータサイエンティストやエンジニアの方にも参加してもらえたら、また違った視点でインスピレーションがあるのではないかとおもいました。

最後まで読んでいただき、ありがとうございました!

Hibaru

お問い合わせ対応の改善取り組みについて

サーバーサイドエンジニアの岡本です。BUYMAの出品者向け機能の開発を担当しています。

弊社のエンジニアチームでは、昨年後半からいわゆる「お問い合わせ対応」の組織的な取り組みを行っておりますので、少しではありますがその取り組みについて紹介したいと思います。

エニグモにおけるお問い合わせ対応

これまで社歴の長いエンジニア数名が対応することが多かったのですが、エンジニア組織体制の見直しに伴い、CS対応の運用方針に関してもテコ入れを行うことになりました。

特定のメンバーがお問い合わせに対応することで他のメンバーに対してナレッジを共有する機会が少なくなり、お問い合わせ対応が属人化してしまうという問題を抱えていました。

BUYMAは機能ごとに大きくSELL/BUY/SI*1の3チーム(以下、ドメインと呼ぶ)に分割している*2ので、各ドメインから一次担当を行うメンバーを選抜し、ドメインごとにお問い合わせに対応する運用を行うようにしました。

運用開始から半年以上が経過しましたので、振り返りを行います。

お問い合わせ対応の流れ

お問い合わせ対応で取り組んでいることは以下になります。

  • 一次対応
  • 再発防止策の検討
  • ナレッジ共有のためのドキュメント作成・定期チケットの作成
  • 休みの共有・緊急時対応への備え

調査

カスタマーサービスチーム(以下、CSチーム)の方がCS対応用のチケットを作成いただき、Slackで連絡していただきます。それをみて対応できそうなメンバーが順次チケットの内容を確認します。

不具合の報告の場合は、弊社で管理しているお客様のアカウント情報をもとにアプリケーションサーバのログを追跡したり、仕様の調査を行います。調査が終わればチケットに調査内容を記載した上でCSチームの方に連絡をします。ここで、チケット作成から一次調査完了までのスパンをできるだけ短くできるように各自心掛けています。CSチームの方が調査が難航する場合もありますので、その場合はお断りを入れた上で調査を続けます。

調査の上でアプリケーションコードの修正が必要な場合は対応を行います。別途起票をして対応することが多いです。

データ補正が必要な場合は修正用のSQL文を作成し、レビューを経た上で本番のDBサーバに対して実行します。

一次対応の流れ

対応したチケットはスプレッドシートに記載をして、ふりかえりを行う際や別のお問い合わせの調査を行う際に活用しています。

調査をしてみて、対応した内容や参照したログ、実行したコマンドなどなどをesa上のドキュメントに記す取り組みも実施しています。ドメインごとに整理でき、とても良いと感じています。

一次対応~対策防止策検討~ふりかえり

休日の対応

有給休暇を取る場合は事前にドメイン内で伝えておき、別のメンバーが対応できる体制を整えています。

また極めて稀ではありますが、土日祝日に緊急対応が必要な場合がありますので、待機できるメンバーを予め選出しています。

身に付いたことや改善点など

先日、お問い合わせを担当するメンバーに意見を聞き、これまでの取り組みを通じて身についたことや今後の課題などを話しました。

  • 身に付いたこと

    • ログ監視ツールを使ったり該当のログサーバにsshするなどして、アクセスログやスナップショットを参照する方法が身についた
    • BUYMAビジネスロジックを理解する機会が増えた。また、自身の担当ドメイン以外のコードも読む機会が増えた
    • 作業見積もりの能力
      • 例えば、午後1時にお問い合わせがきたら調査や作業に4時間くらい確保できると見積もり、その時間内でできそうなことを予想する。
      • 限られた時間内で出来る複数の対応策を提案する
    • CSチームのメンバーとの連携、検索やモバイルなど他チームとの連携を仰ぐ
  • 今後改善できそうなこと

    • 個人的なマインドセット
      • 寄せられるお問い合わせに怯まず淡々とやる
      • 依頼を受けてから返答するまでの時間の短縮・判断力の向上
    • 組織的仕組みづくり
      • 属人化しないために調査手順ドキュメントや仕様の拡充
      • お問い合わせ対応のリードタイム計測
      • バグ傾向の分析
        • お問い合わせ報告が多い機能を分析し、改善につなげる。
        • 定期チケットの作成

プラスになる点として、BUYMA及びECサイトドメイン知識が身につくのは大きいと思います。私も入社して3年目となり、担当している出品者向け機能について少しは知っていると思いますが、まだ把握し切れていない仕様・機能は多くあります。特に決済や配送方法は難しい…。日々のお問い合わせ対応を通じて知見をアップデートしています。

改善点は様々ありますが、隔週で定例会議を行っており、日々改善に向けて取り組んでいます。

株式会社エニグモ すべての求人一覧

hrmos.co

*1:SELLは出品者向け機能、BUYは購入者向け機能、SIは決済や配送などサービス基盤を担当

*2:モバイルアプリやデータ分析や機械学習系や企画系などチームは他にもあります

AWS未経験の新卒エンジニアがAWS JumpStartに参加した感想

こんにちは、22卒エンジニアの 川本 です。

先日「AWS JumpStart 2023 設計編」という研修に参加してきました。

2日間と短い時間でしたが、とても内容が濃くて勉強になったので、本記事では研修の内容や参加した感想を綴っていきたいと思います。

AWS JumpStartとは?

AWS公式HPでは以下のように書かれております。

AWS JumpStart 2023 設計編」はAWS 初学者のエンジニアの方々を対象とした、実践的な研修プログラムです

将来的にAWS 活用をリードする人材になるための第一歩をスムーズに踏み出せるようなプログラムをご提供します

単なるAWS サービスの学習だけでなく、要件に合わせて適切なアーキテクチャを検討・設計する経験を積む部分にフォーカスした内容となっております

例えば、以下のような方々にもオススメです!

AWS の名前は知ってるが使ったことは無い

・ EC2 等の単体サービスは触ったことあるが、全体のアーキテクティングは経験がない

クラウドネイティブなアプリケーションを設計する上で重要な観点を知りたい

AWS初学者向けのクラウドアーキテクチャを検討・設計するイベントで、参加人数が600人以上いる大規模イベントでした。

プログラム内容

研修は以下の構成で行われました。

  1. 事前学習
  2. ハンズオン
  3. グループワーク

事前学習

研修参加前に事前学習として、AWS SAA向けの動画学習教材が送られてくるのでそちらでAWSの基本的なサービスについて学習します。

また、AWSのサービス説明だけでなく、アーキテクティングのコツみたいな内容も盛り込まれており、研修当日に非常に役に立ちました。

私は完全にAWS未経験だったため、こちらの教材で事前学習しておいてほんとによかったです。

ハンズオン

1日目にまずハンズオンがあり、AWS上にTodo管理アプリを構築するといった内容でした。

以下の図のように ALB + ECS on Fargate + Aurora MySQLアーキテクチャを構築しました。

ハンズオンの中で面白くて勉強になったのが、上記のアーキテクチャでECSタスクを片方停止させたときの挙動や、Aurora MySQLのフェールオーバーを実行したときの挙動を実際に手を動かして確認したことです。

ECSタスクが片方死んでも自動復旧している様子や、フェールオーバーしたことによりAurora MySQLのリーダーとライターが切り替わる様子を確認することができました。

このような実践的なハンズオンのおかげで、可用性やスーケラビリティを意識したアーキテクチャとはどういうことなのかというイメージがより具体的になりました。

また、ここまでのアーキテクチャを個人で作成するとお金がかかりますが、その辺りを意識せずにAWSサービスを触ることができるのもうれしいポイントですね!

グループワーク

2日目はグループで課題に沿ったアーキテクチャを構築するといった内容でした。

以下のような要件を満たすECサイトを構築してくださいという課題が与えられました。

  • 提供規模
    • 利用者数:数万人
    • ピーク時間帯:日本時間の朝夕
    • 提供エリア:日本
    • 提供プラットフォーム:web
  • システム要件
    • バックエンド:Java/Spring Boot(Dockerで開発中)
    • フロントエンド:TypeScript/ReactJS
    • データベース:MySQL
  • 必須機能
    • 商品一覧ページ
      • 商品情報
      • 商品画像
    • カート機能、購入機能
      • 決済、在庫管理、配送システムは外部のSaaS APIを利用するものとする
    • アカウント管理機能
  • 追加要件

普段からBUYMAの開発をしておりECサービスには馴染みがあったのでイメージしやすかったです。

しかしBUYMAは全ての箇所でAWS上のサービスを使っているわけではありません。

なので、BUYMAのこの部分はAWSだとこのサービスが使えるなというような観点でアーキテクチャを構築していきました。

このような観点でアーキテクチャを構築することでBUYMAへの理解も深まったので、私にとっては一石二鳥な課題内容でした。

最終的に構築したアーキテクチャは以下構成図です↓

工夫した点としては、

  • ECS on Fargateの構成によりコンテナのAutoScalingを実現してサーバーの可用性up
  • RDSはMulti-AZ構成として、障害発生時にフェールオーバーしてリーダー、ライターインスタンスが切り替わるようにして可用性up
  • ElastiCacheを使うことでデータベースクエリのレスポンスを高速化
  • Cloud Frontを使うことで静的コンテンツ配信の高速化

他にもCI/CDの整備やBIツールの導入、レコメンド機能への対応などを行いましたが、AWSにはそれぞれに適したサービスが用意されており、本当にサービスの種類が豊富だなと思いました。

研修を終えた感想

参加前はAWSについてはなんとなくサービス名を知っている程度でしたが、研修で実際にハンズオンで手を動かしたり、チームでアーキテクチャ議論をすることでAWSの全体感を掴むことができました。

また、Webアプリケーションのアーキテクチャを設計する上で意識すべき可用性やスケーラビリティについて学べたことが大きな収穫だったかなと思います。

AWSのサービス名について知っていても、アーキテクチャを設計する上で重要なことがわかっていないと適切なサービスを選択することもできませんし、設計することもできないと感じました。

最後に

今回の研修を機にインフラのことについても少し興味が湧きました。 AWS SAAの資格取得なども目指していきたいです。

最後に、このような素晴らしい研修を無償で開催してくださったアマゾン ウェブ サービス ジャパン合同会社の皆さま、ありがとうございました!

株式会社エニグモ すべての求人一覧

hrmos.co