DatadogでDocker監視が幸せになった話

こんにちは、エンジニアリングGの安田(@dasoran2)です。7月に入社してAI・機械学習チームに所属しています。趣味は猫耳で入社早々会社では猫耳エンジニアとしての地位を確立しつつあります。

今回は転職早々ではあるものの、自分のチームでDatadogをトライアル導入したのでその話を書きます。

本稿は以下のような内容をお話しします。

• Datadogを選んだ理由
• DatadogでのDocker監視の概要
• Datadogでハマったところ

*1

事の発端

チーム内でレスポンスタイムに問題が発生して、その原因を調査する機会がありました。

しかし、メトリクスがCloudWatchで収集されているもののほかになく、それ以上を取るにはインスタンスやコンテナの中に入って収集する必要がありました。そのため、迅速な対応ができずこの状況を打破したいと考え各種導入検討を開始しました。

Datadogを選んだ理由

基本的にはメトリクスが取れればよかったためDatadog以外も検討したのですが、最終的にはDatadogを選択しました。

小さな理由としては

• UIが綺麗
• ダッシュボードのカスタマイズ性の高さ
• レスポンスに対する悪評がなかった

などありますが、大きな理由は

• Dockerのメトリクス取得をしっかりサポートしている
• AWSのリソースが取れる
  • しかも(現状)無料

この点でした。

そして特にDockerのメトリクス取得がかなりよかったのでこの魅力をお伝えしたいと思います。

*1:アイコンがかわいい

夏の2週間エンジニアインターン記

こんにちは、エムスリーのエンジニアリングG AI・機械学習チームで今年の8月の2週間ほどインターンをしていました丸尾です。

今回は、2週間という短めの期間ですが、内容の濃いインターン活動ができたいと思い、インターンの内容や雰囲気をお伝えしようと思います。

エムスリーのエンジニアインターンの良いところ

初めに、エムスリーのエンジニアリングGのインターンの良かったところを挙げたいと思います。これからインターンに参加しようと考えている方はぜひ参考にしてください！

• 自分の興味やスキルセットに合わせてインターンの内容を決められたこと
• モダンな開発を体験できたこと
• 複数名のエンジニアの方と面談ができたこと

この3点は、この2週間で特に印象に残ったポイントで、エムスリーのインターンに参加できて良かったなあと思いました。

インターン中に実施するタスクとは別に、エムスリー内の複数名のエンジニアの方との1対1の面談の時間を作っていただけました。その際にエンジニアのキャリアの話や、エムスリーにおけるエンジニアリングについてお聞きすることができ、今後のキャリア選択についてとても参考になりました。

インターンで実装した内容

エムスリー内では、データ周りに以下の問題を抱えていました。

• 欲しいデータがどこにあるのかわからない
• あるデータをどのように使ったらいいのかわからない

今回のインターンでは、これらの解決の一歩として、データベースのメタデータ検索ツールの作成を行い、次のような機能を実装しました。

• データベースのメタデータの検索機能
• 該当テーブルを利用しているSQLのクエリ例を表示できる
  • 社内Re:dashのクエリから取得

今回のインターンで実装したツール「Jensen」の画面

初日

ここからは、時系列で今回のインターンの雰囲気をお伝えしようと思います。

初日は、まずはパソコンのセットアップや、アカウントの設定などで半日が過ぎ、お昼頃にメンターの笹川さんと相談してどんな内容のタスクにするかを話し合いました。 笹川さんは、笑顔が絶えない筋肉系エンジニアです。

www.m3tech.blog

このブログによると、 AI・機械学習チームのリーダーはベンチプレスで決まるそうですが、チームの方々はキャラが濃くて面白い人ばかりでした。

今回のインターンでは、データ周り（特にBigQuery）を触ったり、プログラミングを中心にやりたいという私自身の希望があり、またエムスリーのデータ周りの課題がうまく重なり、前述のデータベースのメターデータ検索ツールを作成することになりました。

AI・機械学習チームでは、プロジェクトの名前をアルファベット順でArchimedes, Bourbakiといった数学者や物理学者の名前をつけており、今回のプロジェクトは『Jensen』 に決定しました。（Jensenはイェンセンの不等式などで有名な数学者です）

私は、Ruby on Rails の経験があったので、Railsを用いてアプリケーションを立ち上げました。チーム全体で、GitlabやDockerを用いた開発をしており、モダンな開発環境が整っていました。

1週間目

1週目で、最低限の機能として、ログイン機能とメタデータの検索機能をなんとか作り終え、この後、どんな機能を追加していこうか悩んでいました。その時に、VPoE兼プロダクトマネージャの山崎さんに、一旦デプロイしてフィードバックをもらった方が良いと言われ、簡易的にデプロイして、社内に公開することにしました。

後から振り返ると、早めに社内に公開したことはとても良かったと思います。公開と同時にフィードバックのためのアンケートを作成して、次の週ではそのアンケートを元に、Jensenが目指す方向性について深く考えることができました。

2週間目

2週目では、フィードバックを元に、Jensenの機能をどう拡張していくかを考えました。1週目では、とりあえずメタデータの検索機能を実装しましたが、さらに一歩踏み込んで、エムスリーの全員がデータを活用できるようにする にはどうすれば良いか、そのためには、どんなツールを活用していき、Jensenはどの領域を担うのか、ということをメンターの笹川さんと、チームの安田さんと議論をしました。今振り返ると、この議論がインターンの中でもっとも本質的なことだったかなと思います。

フィードバックの中に、各テーブルに対するSQLクエリの例があると便利だという要望がありました。 エムスリーでは、Re:dashというダッシュボードツールを使い始めていており、SQLクエリの例がある程度溜まっていました。これをJensen上で、テーブルごとにRe:dashのクエリを紐づけることで、よりテーブルの中身を理解できるようにしました。

インターンを終えて

最初は、必要最低限の機能を作ることに精一杯でしたが、後半はただプログラミングするだけでなく、目的に対してどういう課題があり、課題に対してどうやって解決するか、ということを真剣に考えることができました。

一人でプログラミングを勉強するだけではこのような経験はできないことで、実務でプログラミングをするということを実感した貴重な経験になりました。

左から、メンターの笹川さん、私（丸尾）、安田さん

コードレビューをしていただいたり、技術的指導をしていただいたり、一緒に議論していただいたり、キャリアについて相談していただいたりと、大変お世話になりました。改めてありがとうございました！

エムスリーでのインターンに興味を持った方は、ぜひ下のリンクから応募してください！ jobs.m3.com

タイムゾーンを考慮した日時の扱いのベストプラクティス

こんにちは、server-side kotlin や terraform を書くことが多い、エンジニアリングGの矢崎(id:Saiya)です。

タイムゾーンや日時の扱いについての話題がホットな昨今ですが、 そういった日時の扱いについて例えば以下のようなお話を受けることが少なからずありました:

• とりあえず日時は UTC からの時差情報付きで扱えばいいんでしょ？
• DB に保存するときもタイムゾーン情報付きで入れておけばいいんでしょ？

こういったお話を振られた際に、思うところを一言でサッと説明できずもやもやする事もあり、 また web サービスにおいて日時・タイムゾーン・オフセットをどう扱うべきか？納得の行く説明をあまり見つけられなかったため、 筆者なりに考えをまとめてみました。

国家的祭典のために急にサマータイムが導入されるといった話に限らず、 クラウドサービスが UTC+0 の日時になっているがユーザー層は日本時間である、といった理由でも タイムゾーンや UTC オフセット (時差) を扱う必要性のある時代ですので、ご参考にしていただければと思います。

TL;DR

• ユーザーとの日時(LocalDateTime)の解釈や表示処理では、地域のタイムゾーン("Asia/Tokyo" など)に基く日時(ZonedDateTime)を用いる
  • LocalDateTime の例: 2018-08-09 00:56:34
  • ZonedDateTime の例: 2018-08-09 00:56:34 (Asia/Tokyo)
• システム間の日時情報のやりとりや DB・ファイルなどへの日時の保存では、UTC からのオフセット情報付きの日時 (OffsetDateTime) を利用する *1
  • OffsetDateTime の例: 2018-08-09T00:56:34+09:00
  • API などでは上記のような ISO-8601 の拡張形式 が最近の主流

なお、LocalDateTime, ZonedDateTime, OffsetDateTime という用語は Java 8 Date and Time API (JSR-310) の表現を借用していますが、 本稿の内容や考え方は Java 固有ではありません。

以下、詳細を説明します:

*1:とはいえ DB のデータ型の都合などで UTC からのオフセット情報を持てない場合は、一定のオフセットに揃えたうえでオフセット情報なしで保存するしかないです

エンジニア新人研修、始めました。

こんにちは、エンジニアリングGの池田(@progrhyme)です。

エムスリーではこれまでエンジニアの集団研修を実施しておりませんでしたが、昨年度に続き新卒採用のエンジニアが若干名入社したことをきっかけに、新人研修を企画して実施しました。

手探りではありましたが、最終的に5〜7月にかけて12本の講義を実施し、のべ250以上の受講数*1を達成することができました。

本記事では、その内容の一部を紹介し、簡単に振り返ってみます。

*1:1人1講義の受講を1とカウント

プロダクトマネージャー@エムスリーのご紹介

エンジニアリングGプロダクトマネージャーの境です。

エムスリーといえばm3.comを思い浮かべる方も多いかと思いますが、実はその他にも様々なサービスを展開しています。そのような環境の中で、私の所属するエンジニアリングG新規事業チーム(仮)のプロダクトマネージャーがどのような仕事をしているか少しご紹介します。

背景

エムスリーでは毎年、数十もの新規事業が立ち上がります。ソフトウェアプロダクトの開発が必要な案件に関しては、その事業の特性に近い既存サイト/サービスの責任者が主導することが多いです。しかし、中にはソフトウェアプロダクトの開発が必須だが、既存サイトやサービスとは全く異なる性格であるため、既存チームにお願いするのがなかなか難しいものもあります。そういった案件に対して仮説検証フェーズから参加し、ビジネスとして成り立つプロダクトへ成長させていくことが私が所属しているチームのミッションです。

プロダクトマネージャーとは？

プロダクトマネージメントについて書かれた名著「Inspired: 顧客の心を捉える製品の創り方」では次のように説明されています。

通常、新しい製品のアイディアは、あらゆるところから飛び出してくる。例えば、経営陣、客先との議論、ユーザービリティテスト（製品の使い勝手を検証するテスト）からのフィードバック、製品開発チーム自身、営業担当者、業界関係者などだ。が、次に、誰かがそのアイディアを吟味して、製品化を進める価値のあるものかどうかを判断しなければならない。この目利きをやるのが、プロダクトマネージャーだ。
出展元 : Inspired: 顧客の心を捉える製品の創り方

このように、ソフトウェアプロダクト開発において「何を作るべきか」を定義し、「なぜ作るべきか」をメンバーに説明する役割を担います。

実は、プロダクトマネージャーの職責はもっと広いのですが、一義的には上記の定義で十分なので、今回は上記の定義を前提にします。 興味のある方はこちらを参照下さい。

プロダクトマネジメントトライアングル: プロダクトマネージャーの職責を説明するときによく用いられます。
引用元: https://ninjinkun.hatenablog.com/entry/the-product-management-triangle-ja

どのようなプロダクトがあるの？

私が主に担当させていただいているのは、

• 医療人材のマッチングサービス (価値仮説検証フェーズ)
• AIを使用した自動診断サービス (MVP開発フェーズ)
• 電子カルテサービス (グロースフェーズ)

です。
事業領域もプロダクトのフェーズも本当に多岐に渡ります。この他にも社内には新規事業のアイディアがごろごろ転がっています。硬軟新旧、本当に様々なサービスやビジネスアイディアに毎日触れることができるため、本当に刺激的な環境でワクワクします。しかも、サービスはどれも社会的意義が豊かなので、頑張れば頑張るほど、なんかいいことをした気分になれるおまけ付きです。すばらしいですね。

どんな感じでプロダクトマネジメントしているの？

これはプロダクトのフェーズによって内容は大きく異なります。 例えば、価値仮説検証フェーズですと、解決すべき課題が曖昧であったり、実はそこまで課題ではないことがしばしばあるため、リーンに仮説の立案と検証を繰り返すことがとても重要です。ですので、しっかりといいものを作りたい気持ちをぐっと抑えて、アンケートやユーザーインタビューを実施したり、外部サービスを組み合わせてプロトタイプを提供したりと可能な限り手間のかからないシンプルなソリューションで、仮説の検証を進めます。

MVP開発フェーズでは、必要最小限の機能をいかにすばやく作り、リリースするかが重要です。価値仮説検証フェーズを経たことで、解決すべき課題と提供すべき価値が明確になりました。MVP開発フェーズではこれをソフトウェアプロダクトという具体的な形に描くことになります。その時、「もっとこうしたらユーザーにとってより使いやすくなるのではないか」といった誘惑や、「この機能がなくて本当にユーザーは不満に感じないだろうか」といった不安に襲われ、ついつい作り込み過ぎてしまうケースがあります。しかし、必要な機能かどうかはリリースしたプロダクトをユーザーに使用していただき、フィードバックをいただくまで判断できません。なので、そういった機能は勇気を持って排除し、少しでも早くリリースできるように準備を整えるべきです。

グロースフェーズになると、日々ユーザーからいただくフィードバックを着実にプロダクトに反映しつつも、それに加えて、ユーザーに驚きを届けることが重要になります。そこで、「うちだからこそ解決できるユーザーの課題はなにか」や「5年後、10年後にプロダクトのあるべき姿」を想像し、高い技術力を活かしたプロダクト開発を進めています。

プロダクトマネジメントについてより詳しく知りたい方は弊社VPoE兼プロダクトマネージャーの山崎が書いた記事が詳しいので、ごらんください。

他にもインターンに参加していただいた学生のメンターもしております。テックブログにて詳しく感想を書いていただいたのでそちらもよろしければ読んでみて下さい。

プロダクトマネージャーが複数プロダクト担当なんて無茶では？

幸いなことに、弊社はビジネスサイド、エンジニアサイドに関わらず、メンバーに非常に恵まれており、プロダクトのフェーズもうまく分散しているため、いまのところなんとかなっています。
異なるフェーズのプロダクトを同時に複数担当させてもらえることで、飛躍的な成長を実感する日々ではあるのですが、仮に私が担当しているプロダクトがすべて正式リリースとなると、私がボトルネックになることは明らかです。

ただそのくらいやりたいことが溢れているのです。

そこで、プロダクトマネージャーを募集しています！

エンジニアリングG新規事業チーム(仮)では、プロダクトマネージャーとして新しいプロダクトを一緒にドライブしてくれる仲間を募集しています。
医療業界にはITの力で大きく変革できる領域がまだまだたくさん残されています。
猛烈に優秀なメンバーと共に、健康で楽しく長生きする人を一人でも増やせるサービスを作りませんか。
興味が湧いた方はぜひ Tech Talk やカジュアル面談にお越しください。 お問い合わせは以下フォームより、お待ちしております。 jobs.m3.com

デプロイの度に障害が起きるシステムを安全にした話

鉄道では個人の注意力だけでなくシステムにより安全を確保している。 写真は「タブレット閉塞式」のタブレットを交換する様子。１つの区間にはタブレットを持った列車しか進入できないため、衝突事故を防ぐことができる。（作者 Spbear [CC BY-SA 3.0 ], ウィキメディア・コモンズより）

こんにちは、エムスリーでソフトウェアエンジニアとして働いている小本です。

私は基盤開発チームという、エムスリーの複数のサービスにまたがって使われるシステムを開発・運用するチームに所属しています。 基盤開発チームが担当するシステムの１つに、会員向けメルマガの配信システム「メールコンシェルジュ」があります¹。

エムスリーはメールコンシェルジュで１日数十万通のメルマガを配信しており、機械学習でメルマガを最適化する施策²などもメールコンシェルジュの存在が前提になっています。

このようにエムスリーにとって重要なシステムなのですが、メールコンシェルジュは数年前まで運用、特にデプロイに問題を抱えていました。デプロイ時のミスによる配信障害が頻繁に発生し新人がデプロイすると必ず障害を起きるという状況だったのです。また、1回デプロイするのに30分かかり、デプロイ中はメルマガの配信ができませんでした。

---

1. Ruby on Railsで作られており、DBや社内システムとの連携、開封率やクリック率の計測、A/Bテスト、など商用サービスと遜色無いほど高機能なアプリケーションなのですが、それについては別の機会に紹介します。↩

2. このあたりは、別の記事で紹介されると思います。↩

ダジャレ TechTalk

エムスリーソフトウェアエンジニアの大瀧です。 AI・機械学習チームで自然言語処理/推薦システムの開発を行なっています。 スタンドアップ・ミーティングをダジャレで締め括る役割も担っている私が、M3 Tech Talkの雰囲気をお伝えしたいと思います。

エムスリーにおけるTech Talk

エムスリーでは毎月2回、TechTalk を開催しています。 テーマは非常に幅が広く、「クラウド・Saas/Paas/Iaas」「セキュリティ」から「心構え・エモい話」まで様々！

過去数回分発表を振り返ってみると、こんなテーマがありました。

• VTuberを支える技術
• 非同期タスクの処理系を作ってみた
• crazy-js Quiz
• 5G(2020年のモバイル通信)
• 問題解決入門
• 消防で行なった業務改善の取り組み（Electron-Vueの利用）

発表の例として、私大瀧が6/20に発表した「ダジャレ判定における自然言語処理技術」を紹介させて頂きます。 M3 Tech Talkの雰囲気（の一部）を味わって頂き、M3 Tech Talk（もちろん、エムスリーにも）に興味を持って頂ければ幸いです

ダジャレ判定における自然言語処理技術

この発表で伝えたいこと

1. 自然言語処理の難しい部分は、曖昧さの扱いの部分である
2. 汎用ダジャレ判定アルゴリズム開発は、汎用人工知能開発に繋がっている（かもしれない）

発表の流れ

1. 過去 ：@oboenikui の身に起きた悲劇（この発表のキッカケ）
2. 現在：ダジャレ判定アルゴリズムの改善
3. 未来：ダジャレ判定アルゴリズムが超えるべき壁

過去編

あらすじ

最近、同僚のTwitterアカウントに悲劇が起きました。 ダジャレ検出機能を搭載したbotの誤作動に、巻き込まれたのです。

某氏の婚約者の写真がチラチラ見える

— おぼ (@oboenikui) 2018年4月4日

その後の彼のツイートを読んで、ここ（M3 Tech Talk）で話すことにしました。

（なお、このあとすぐに社内のダジャレ第一人者に絡まれていました）

従来のアルゴリズム

既存手法は、以下のような流れでダジャレを判定します。

参考：文章からダジャレのみを抜き出すコマンドを作ってみた

1. 形態素解析
2. 文中に登場する名詞と同じ「読み」の個数をカウント
3. 文中に登場する名詞と同じ単語をカウント
4. 読みの個数カウント > 単語の個数カウント ならダジャレ

従来のダジャレ判定アルゴリズムの優れた点は3. の同じ単語をカウントし判定の条件とした点で、 「人民の人民による人民のための政治」などの同じ単語が複数回出現する例をダジャレではないと判定することができます。

私は上記の参考記事と出会った際、感動し、多くのダジャレを入力して楽しみました。 とある（ダジャレだと信じている）例を入力した際に、私はこのアルゴリズムの改善を決意しました。 従来アルゴリズムは布団が吹っ飛んだをダジャレではないと判定していたのです。

現在編

改善方法

私がアルゴリズムの改善に用いたアイデアは、ダジャレの領域知識と言っても良いものです。 ダジャレは、音の違いに関して非常に寛容なのです。 （音が少しぐらい異なっても同じものと見て良く、曖昧さの扱いを頑張るべきところです。）

この特徴から、「2. 文中に登場する名詞と同じ「読み」の個数をカウント」の際に促音、撥音、拗音、聴音を除去することにしました。

この処理により、布団が吹っ飛んだをダジャレであると判定することができるようになりました。

課題

しかし、（当然ながら）これですべてのダジャレが正しく判定できるようになったわけではありません。

未来編

これからは「足湯で疲れをフットバス」を始めとした、 音の直接的な重なりがないダジャレの判定にチャレンジしていきます。

将来的には「ある人にとってのダジャレ感性/判定の再現」を目指していきたいのですが、 その際我々は「人間のダジャレの定義の曖昧さ」と戦うことになるでしょう。 ※ 我々：ダジャレ判定アルゴリズム開発者

「どれほどのパターンがあるのか」「ダジャレの定義をアルゴリズムに記述しきれるのか」... ひとまず私自身の思考形態を模倣しながら、人間がどのように知識を表現する/物事を結び付けるのかを模倣/生成/学習できるようなものを目指していくつもりです

（有り得るすべての知識の使い方に対処できない、「ダジャレのフレーム問題」との闘いになるような気がしています）

まだ見ぬダジャレに出会うため、私は究極のダジャレ判定/生成アルゴリズムを追い続けます。 どんな困難な道だとしても。

まとめ

以上が、M3 Tech Talk（6/20）での発表内容です。 M3 Tech Talkでの発表はどれも、アツい想いが込められたものだと感じています。 M3 Tech Talkの雰囲気が、少しでも伝わっていれば嬉しいです。

現在もダジャレ判定アルゴリズムは発展の気配を見せており、 そのアルゴリズムの一部は 8/10 のM3 Tech Talkで発表予定です。 少しでも興味を持ったなら、↓の応募フォームからTech Talkへの参加申し込みを！

1度だけでなく、ちょこちょこ聴講 して下さるとさらに嬉しいです

エンジニア募集

エムスリーでは、技術で医療の課題を解決するエンジニアを募集しています。 この記事を読んで興味を持った方はぜひ下記リンクよりご応募ください。 ダジャレ名人も、沢山所属していますよ！

jobs.m3.com

docs.google.com