エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

エンジニアリングバックグラウンドのプロダクトマネージャーがVPoEを兼任するメリット・デメリット

こんにちは。エムスリーエンジニアリンググループVPoE兼プロダクトマネージャーの山崎です。

本ブログはProduct Manager Advent Calendar 2019の9日目の記事です。

エンジニアリングバックグラウンドのプロダクトマネージャーがVPoEを兼任している組織は、もしかしたら珍しいかと思い、今回のブログでは、自分の経験を例に、そのメリット・デメリットついて書いていきたいと思います。

ちなみにエムスリーエンジニアリンググループでは、エムスリー Advent Calendar 2019を絶賛更新中*1ですので、ご興味のある方は是非こちらもご覧ください。

qiita.com

*1:私は12/25担当なのでお楽しみに!

続きを読む

Cloud Run で NEWS ランキング API を作った話

エンジニアリンググループ AI・機械学習チームの岩月です。

これは エムスリー Advent Calendar 2019 の12月8日の記事です。

今回は、先日ついにGAになった Cloud Run を利用して、 NEWS のランキング API を作成した件についてまとめます。

  • NEWS ランキング API の役割
  • Cloud Run
  • 構成
  • 処理のフロー
  • なぜこの構成になったか (Cloud Run を採用してよかった点)
    • 運用のコストを減らしたかった
    • GKE (Kubernetes) への移行がしやすい
    • Cloud Run を使いたかった
  • Cloud Run を採用したことによる制限
    • Keep-Alive ができない
    • コールドスタート
  • まとめ
  • We're hiring!

NEWS ランキング API の役割

エムスリーでは医療関連のニュースをはじめとする様々なニュースを扱っており、そこでのユーザーの行動ログは BigQuery にストリームで格納されています。 今回作成した NEWS ランキング API の目的は BigQueryにたまったログを集計したPVランキングを提供する ことです。

続きを読む

MVPアプリを2週間で開発した話 ~プロダクトマネージャーとしての「製品の発見」への取り組み方~

こんにちは。エムスリーエンジニアリンググループ、プロダクトマネージャーの中村です。

エンジニアリンググループでは、エムスリー Advent Calendar 2019を絶賛更新中ですが、本ブログはProduct Manager Advent Calendar 2019の8日目の記事です。

今回のブログでは、先月開催したソフトウェア・ファーストで医療業界を変える!エムスリーのプロダクトマネージャーの働き方紹介という勉強会で発表した、MVPアプリを2週間で作って仮説検証をした話について書きたいと思います。

続きを読む

QAチームの勉強会でアクティブ・ブック・ダイアログを取り入れてわいわいやってみた話

エムスリー Advent Calendar 2019 6日目の記事です。エムスリーエンジニアリンググループ QAチームの城本(@yuki_shiro_823)です。QAチームでよく勉強会を主催したり、直近では、下記の記事で紹介されている新しいアンケートシステムのQAを担当しました。 www.m3tech.blog QAチームでアクティブ・ブック・ダイアログを実施して効率的に学習ができたので、その様子を紹介します。

  • アクティブ・ブック・ダイアログとは?
  • 書籍の選定
  • 実際にやってみた様子
  • 得られた気づき
    • 「患者目線の医療改革」から得られた気づき
    • アクティブブックダイアログについての気づき
  • We Are Hiring!
続きを読む

Amazon SQSに置き換えてパフォーマンスとスケーラビリティを得た話

エムスリー Advent Calendar 2019 5日目の記事です。

やがて君になる、完結しましたね… エンジニアリンググループの山口 (@no_clock) です。

今日は、クラウド電子カルテ「エムスリーデジカル」で、SQSを使ってパフォーマンスとスケーラビリティを得た話です。

  • 前提: 利用施設数の増加と、あまりスケールしないシステム
  • 課題: 診療データクローラ
    • 診療データクローラとは何か
    • クローラの遅延
    • クローラを続けるか、やめるか
  • 解決: 診療データ『キュー』
  • 結果: パフォーマンスとスケーラビリティ
  • おまけ: We are hiring!
続きを読む

Kubernetes上でのGoによるシンプルなAPIの開発と、その効率化のためのcookiecutter templateを作った話

エンジニアリンググループ AI・機械学習チームの笹川です。

これはエムスリー Advent Calendar 2019の12月4日の記事です。

前日は、CTO 矢崎による 1つの terraform で複数 AWS Account をまとめて構築・管理する でした。

今回は、AIチームでのAPI開発で利用している技術の紹介と、開発の効率化のため、プロジェクトの雛形を自動的に生成するcookiecutterのプロジェクトテンプレートを作成した件について紹介します。

qiita.com

  • 背景
  • プロジェクトテンプレートの実装
    • APIとリポジトリの構成
    • プロジェクトの内容
      • GoaのDSLファイル
      • Dockerfile
      • Kubernetesの設定ファイル各種
      • 負荷試験用のシナリオファイル
  • まとめ
  • We're hiring!
続きを読む

1つの terraform で複数 AWS Account をまとめて構築・管理する

この記事は terraform Advent Calendar 2019, エムスリー Advent Calendar 2019 の 3 日目の記事です。

f:id:Saiya:20191110233938p:plain:w300
All your AWS Accounts are belong to us. *1

こんにちは、ここ数年で terraform で書いた aws_vpc + google_compute_network の数がようやっと 30 個ぐらいになろうかというエンジニア/CTOの矢崎 id:saiya です。

弊社でまとまった規模の AWS 環境を扱う際に、1 つの terraform プロジェクトで複数の AWS アカウントに対してまとめて plan & apply できるようにしていたのですが、その方法が意外と調べにくい様子でしたので、まとめてみました。

なお、やり方が分かってしまえば実施するのは結構簡単です。

これによって出来ること

  • 1 回の terraform apply で複数の AWS アカウントを一度に操作できるようになります
  • 1 つの terraform の中で複数の AWS アカウントのリソースを相互に参照できるので、アカウント間で相互依存する記述を非常に素直・シンプルに記述できます
    • 例えば VPC Peering の これこれ のペアを 1 ファイルにまとめて書いたりできます。Transit Gateway でも同様。

なお、今回紹介する手法ではアカウントが同一 AWS Organization に属する必要もありません *2

*1:ずいぶん変な英語だなぁ、と思った方はこちらをご参照ください: https://ja.wikipedia.org/wiki/All_your_base_are_belong_to_us

*2:Transit Gateway などの活用を考えると属していたほうが便利ですが

続きを読む