エムスリーテックブログ

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

GitLab CIの実行時間を15%短縮した話

はじめまして、エンジニアリンググループの山口です。9月にjoinし、クラウド型電子カルテ「デジカル」を開発しています(今後「エムスリーデジカル」として本格展開することがプレスリリースで発表されました!)。

今回は、テスト並列化や札束ビンタ以外の方法で、GitLab CIの実行時間を15%短縮した話です。

3行でまとめると

  • GitLab CIのrawログに隠し要素がある
  • 原因の深掘り大事
  • キャッシュを雑に設定してはいけない

前提: デジカルの開発スタイル

デジカルは、 Ruby, Scala, Java, JavaScript と複数の言語を組み合わせてサービスを構成しています。

チームの開発スタイルは以下の通りで、比較的安全に開発が進められるようになっています。

  • git-flowに近い開発フロー
  • GitLab CIによるビルド、ユニットテスト、静的解析
  • 窓が壊れているのを放置しない (割れ窓理論 - Wikipedia)
    • 誰もレビューしていない状態でマージしない
    • CIが通らない状態でマージやリリースをしない

ただし、改善の余地は山ほどあります。そのひとつは、"CIの遅さ"でした。

問題: CIが遅いことによる弊害

CIは、全ジョブ合計で1時間半近く掛かっていました。依存関係のないジョブを複数ランナーで並列実行しても40分。遅い。

f:id:t-yamag:20181105123720p:plain

CIの遅さによって、主に2つの問題が生じていました。

hotfixリリースに時間が掛かる

好ましくはありませんが、何らかの理由で急いでリリースする場合があります。

その際、CIが通ってからリリースするようにしているため、CIの遅さはそのままリリースの遅さに直結します。仮に不具合の修正だとすると、修正の適用がそれだけ遅れます。これは問題です*1

また、それを認識した上でCIを待たなければならない、という精神的な辛さもあります。

コンテキストスイッチに時間が掛かる

時々CIの通らないpushをしてしまうこともあります。しかし、その失敗が通知されるのは、最悪の場合1時間半後です。

もう内容はほとんど覚えていません。なんだっけ、と思い出す時間が積み上がります。

原因: なぜCIが遅いのか?

この問題に対処することを決め、早速原因を探っていきます。

*1:念の為ですが、CIを通さずにリリースするのは、リスクを考えると現実的ではないため実施していません

続きを読む

M3 USA 出張記 #3: SPA を CloudFront + S3 でシンプルにデプロイしてみました

こんにちは、エンジニアリングGの矢崎です。

最近は M3 USA で仕事をしており、下記の前回の記事でご紹介した Headless CMS Contentful を利用するアプリケーションを React の Single Page Application (SPA)で作っています。

www.m3tech.blog

コードはほぼ全てフロントエンドの SPA で実装するアーキテクチャなのですが、そのようなアプリケーションを CloudFront でデプロイする際に工夫した点や知見のご共有です。

CloudFront

f:id:Saiya:20181029221716p:plain

今回、以下のような利点があるため AWS の提供する CDN である CloudFront を利用しました:

  • 初期投資・固定費用が小さい (HTTPS を利用する場合でも, 後述)
  • AWS のエコシステムに乗ることが出来て便利
  • 凝った機能(画像処理など)がない代わり仕様がシンプルであり、挙動や特性が比較的把握しやすい

やったこと

主な作業はこれだけです:

  1. terraform の cloudfront_distribution および cloudfront_origin_access_identity を構築
  2. CI/CD でデプロイ時に SPA アプリをビルド && aws s3 sync && aws cloudfront create-invalidation

筆者は CloudFront を初めて触ったのですが、本番リリースにも利用できる構成が 1 日程度でセットアップできました。実際は既存のオンプレミス環境との DNS の調整や GuardDuty *1のセットアップなどの本件に直接関係ない仕込みもあったのですが、それでも数日程度です。

既に多数の解説記事が世の中にあるので、上記のセットアップのやり方そのものについてはここでは深入りせず、本記事ではセットアップ時に工夫した点・気をつけた方が良いと思われる点をご紹介します。

CloudFront の設定項目について

Infrastructure as a Code 用の自動化ツールである terraform を使う場合は、cloudfront_distribution のドキュメント にある設定項目を一通り見ることで CloudFront の設定項目が一通りわかります。

terraform を使わない場合も、AWS 公式のドキュメントよりもこういったツールの設定項目の一覧を見るほうが把握しやすい気が個人的にはします。

上記の cloudfront_distribution にある設定を一通りやれば動くのですが、実際に使ってみて気づいた興味深い点や工夫した点・留意が必要そうな点について以下に記します:

*1:AWS アカウントを作ったら欠かさず全リージョンに設定しておくと良いです

続きを読む

通年募集!エンジニアインターンのすすめ

人事の友永です。エムスリーでは今年の夏、15名の学生さんにエンジニアインターンへ参加いただきました。 とてもありがたいことに参加者からの満足度も高く「もっとインターンの存在を告知したほうがよいのでは!」とフィードバックをもらいましたので、今回の記事ではエンジニアインターンの紹介をしたいと思います。

  • これから就活をひかえているけど何から始めたらいいかわからない方
  • 既に内定もらったけど意思決定していいか迷っている方
  • 実戦の中で自分の技術力を向上させたい方
  • エムスリーで働くイメージを知りたい方

などに是非読んでいただきたいです。

エンジニアインターンの特徴

  • 実施時期、期間、出社頻度、実施内容を希望に合わせて調整
  • いちエンジニアとして実務に参加
  • メンターが強い、フォローが手厚い
  • チャレンジできる技術スタックが多岐にわたる
  • 時給は2,000円~(オフィスまでの交通費は別途支給)※2018/10時点
  • 遠方在住者には宿泊費と東京までの交通費を補助(当社規定)
  • アウトプットにより本選考時の優遇プロセス有り

まず、エムスリーのインターンは通年で参加者を募集しています。インターンといえば夏休みに参加するものと捉えている学生さんも多いかもしれませんが、エムスリーの場合はお互いの都合が合うタイミングで調整できます。実施期間は2~4週間。週ごとの出社頻度や出社時間もフレキシブルに対応可能です。現在も絶賛インターン参加者募集中です。

実施内容も本人の希望やこれまでの経験を考慮して決定するようにしており、チャレンジできる機会を出来る限り整えています。
これまでの実施テーマや技術スタック例は以下の通りです。ざっとみても多岐にわたっている印象です。

  • 医師向け新規サービス開発(Kotlin/Spring Boot)
  • アンケート集計システム開発(Go/React.js/Kotlin)
  • コンシューマ向けサービス開発(Ruby/Rails/Vue.js)
  • データ分析基盤の開発(Rails/Python/Docker/AWS)
  • メルマガタイトルの短縮(Python/Chainer)

インターン開始前に配属チームや実施内容のすり合わせを行いますので、是非チャレンジしたいことを教えてください!

インターン参加者の感想

インターン自体どんどん改善していきたいので、参加者からインターンに対するフィードバックをもらうようにしています。
サマリーをお伝えすると・・・

■良かった点

  • やりたいことにたくさん挑戦することが出来た
  • ビジネス上の具体的な課題に取り組めた
  • 未経験の分野での業務にもたくさん携われた
  • エンジニアの方々からの指導が厚かった
  • 分からないところは丁寧に教えてくれた
  • メンターが強くて、成長機会が多かった
  • ランチなどで多くの社員さんと関わって会社についてよく知れた
  • 勤務時間が自由で良かった
  • 給与がよかった

■改善してほしい点

  • 配属チーム以外や全体像を知る機会がほしかった
  • ドキュメント管理が分散していて情報を探すのに時間がかかるときがあった
  • 毎朝何をやるべきかの確認時間をとってほしかった
  • インターン生同士の交流がもっとほしかった
  • 気分を変えたい時等にリフレッシュできるスペースがほしかった
  • もっと大々的に宣伝すると良い

多くのフィードバックに感謝すると共に改善点はメンター陣と協力しながらより良くしていく所存です!

インターン生による体験記事もいくつかありますので是非ご覧ください。雰囲気などより伝わるかと思います。

機械学習エンジニアインターンがすごい楽しかった話
夏の2週間エンジニアインターン記
エムスリーインターン体験記(ソフトウェアエンジニア編)
エムスリーインターン体験記(プロダクトマネージャー編)

またインターンに参加し入社を決めたエンジニアもいますので、自分にとってフィットする会社を選ぶ機会としてインターンを活用するのもひとつです。

私と、エムスリーと、ときどきインターン

インターン参加までのプロセス

ここまで読んでいただき、少しでも興味を持っていただ方は是非インターンにご応募いただけると嬉しいです! 基本的なプロセスは以下の通りです。

  1. エントリー
    以下いずれかよりエントリーしてください。 https://open.talentio.com/1/c/m3/requisitions/detail/9150
    https://jobs.m3.com/engineer

  2. WEBプログラミングテスト、SPI (約60分ずつ ) メールでご案内いたします。

  3. エンジニアとの面接(60~90分)※Skype面接可能、服装自由

  4. 配属先や実施日の調整

  5. インターン開始!

いきなりインターンへの応募は不安という方はカジュアル面談(エムスリーやインターンの紹介をします)スタートからでもOKです。カジュアル面談希望の場合はこちらからお問い合わせください。

尚、採用の本選考に進んでもらう途中でインターンに参加いただくことも可能です。本選考へご応募の場合はこちらより該当するポジションを選択しエントリーをお願いします。

まとめ

エムスリーでは通年でインターン参加者を募集しています! 自己成長の為、納得して会社を選びたい方は是非以下サイトからご応募くださいませ。テクノロジーで一緒に医療を前進させましょう! jobs.m3.com

M3 tech meetup! #4 ~医療を支えるエンジニアのLT大会~を開催しました

こんにちは、エムスリー エンジニアリングGの大和です。

去る 9/27 (木) に弊社オフィスにて、「M3 tech meetup! #4 ~医療を支えるエンジニアのLT大会~」を開催しました。

m3-engineer.connpass.com

参加されたエンジニアの皆様におかれましては、当日は弊社までお越しいただきありがとうございました。

発表内容

当日は、以下に紹介するタイトルで弊社エンジニアが登壇しました。

弊社では、二週間に一度 TechTalk とよばれる社内勉強会を開催しており、様々なテーマで発表が行われています。 今回の M3 tech meetup では、弊社エンジニアの雰囲気を知ってもらいエンジニア同士で交流を深めることを目的として、 TechTalk で好評だったテーマ + 新規テーマによる発表となりました。

続きを読む

M3 USA 出張記 #2: 美しい世界観のCMS, Contentful

エンジニアリングGの冨岡(@jooohn1234)です。

M3 USAに出張して1週間少し経とうとしています。初めての週末は、Central Parkを散歩したり、The Metを訪れたり、ShakeShackのハンバーガーを食べたりしてニューヨーカーを気取って過ごしました。(一人で)

f:id:jooohn:20181020012827p:plain
The Met (The Metropolitan Museum of Art)

プライベートの話はともかくとして、今回はUSでの私たちの取り組みと、ContentfulというHeadless CMSサービスについて紹介します。

M3 USAでの取り組み

M3 USAではいくつかのサービスが平行して運用されているのですが、そのなかの一つがMDLinxという医師向けの情報ポータルサイトです。

一見、ニュース記事や論文などのリードオンリーなコンテンツを提供するだけのシンプルなサイトに見えますが、裏側は10年以上の歴史が詰まり、継ぎ足し継ぎ足しでできた巨大な泥団子になっており、記事のレイアウトを少し変えるのにもエンジニアが工数を使って開発しているというのが現状です。

単にライターやエディターがもどかしいだけでなく、開発が全体のボトルネックとなっているため、システムの負債がビジネス上の大きな負債となってしまっています。USと聞くと、シリコンバレーやスタートアップ、技術の最先端をいく華やかな世界の印象が強いですが、こういう泥臭いことも全世界で起こっているんですね!

ともあれ、この状況をなんとかする、というのが私たちのミッションの一つです。

続きを読む

機械学習で便利なluigiフレームワークの紹介

AI・機械学習チームリーダーの西場(@m_nishiba)です。 チームの機械学習系の開発にパイプラインフレームワークとしてluigiを使っています。

(実際にはluigiをラップしたようなモジュールを作っています。そのうち公開しようと思っています。)

今回は、luigiの使い方について紹介しようと思います。

(luigi==2.7.5で動作確認を行っています。)

基本的な使い方

Taskの基本的な書き方

luigiのタスクを作るには、luig.Taskを継承し、下記3つのメソッドをオーバーライドすれば良いです。

  • requires()
    • 依存している他のTaskを返します。このタスクのrunが呼ばれる前にこの関数が返すTaskのrunが呼ばれます。
    • 戻り値はTaskやTaskのlist, dictとなります。
  • run()
    • Taskの実行ロジックを定義します。inputとして、requiresのタスクのoutputが渡されます。何かしらの処理を行いoutput先に出力します。
  • output()
    • Taskの出力先。luigi.Targetやそのlist, dictになります。

実際にHello worldを出力するTaskを書くと次のようになります。

hello_world.py

class OutputHelloWorld(luigi.Task):
    def requires(self):
        pass  # 入力は無し

    def output(self):
        return luigi.LocalTarget('./output/hello_world.txt')

    def run(self):
      with self.output().open('w') as f:
            f.write('Hello world')

if __name__ == '__main__':
    luigi.run()

outputディレクトリを作って、pythonを実行します。

$ python hello_world.py OutputHelloWorld --local-scheduler

===== Luigi Execution Summary =====

Scheduled 1 tasks of which:
* 1 ran successfully:
    - 1 OutputHelloWorld()

This progress looks :) because there were no failed tasks or missing external dependencies

===== Luigi Execution Summary =====

無事に実行でき、output/hello_world.txtが生成されたかと思います。

さらにもう一度実行すると、

===== Luigi Execution Summary =====

Scheduled 1 tasks of which:
* 1 present dependencies were encountered:
    - 1 OutputHelloWorld()

Did not run any tasks
This progress looks :) because there were no failed tasks or missing external dependencies

===== Luigi Execution Summary =====

と表示され、すでにoutput/hello_world.txtが存在するので、OutputHelloWorldは実行されませんでした。 データ分析を行う上で再実行されないのは非常に便利です。

他のタスクに依存するタスク

続きを読む

M3 USA 出張記 #1 : M3 USA 出張のあらまし と 海外長期渡航のTips

2018-10 月から 12 月に掛けて、M3 USA (NY) へエンジニア 3 名(冨岡, 矢崎, および 11 月から笹川)が出張しております。

f:id:Saiya:20181013040249j:plain

US での雰囲気やエンジニアリング面での試みなどを数回に分けて ご紹介するシリーズの第一弾として、NY のオフィスや US への長期渡航の tips をご紹介します。

M3 USA

エムスリー(株)の会社概要の連結子会社の一覧 にありますように、M3 には USA, 英国, フランス, ドイツ, スペイン, 中国, 韓国, インド と数多くの国に関連会社があります *1

そのうちの一つである M3 USA の歴史はインターネットサービスとしては古く、 MDLinx という医療情報提供サービスが 1999 年に始まり、エムスリーグループへの参加も 2006 年にさかのぼります。 今現在でも MDLinx は M3 USA の主要サービスの一つです。

そのように長い歴史があるゆえに、近年に現れた技術などを MDLinx へ導入することで改善や新しい価値を発揮できるポテンシャルがあるというのが技術面での見込みです。

そういった可能性を検討・概念実証すべくエムスリー (日本) のエンジニアが US へ赴いているという状況です。 今回は上記の内容に加えて NY オフィスの様子と海外長期出張の tips をご紹介し、次回以降で技術面でのツールやアプローチ、あるいは NY 滞在にまつわるトピックなどをご紹介しようと思います。

*1:筆者が把握できていないだけで更に他の国にも関連企業があるかもしれません

続きを読む