エムスリーテックブログ

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

Terraformの不要なreplaceを阻止する

この記事はエムスリー SRE がお届けするブログリレーの6日目です。

エムスリー エンジニアリンググループ新卒2年目の四方田 (@k-yomo) です。 現在はBIR(ビジネスインテリジェンス&リサーチ)というチームでソフトウェアエンジニア兼チームSREとして、マイクロサービスの開発や、クラウド環境の整備などを行なっています。

最近はTerraform Providerを作り始めたり等しています。

github.com

エムスリーではInfrastructure as Codeが普及しており、所属しているチームのエンジニアも今では全員Terraformを書いてクラウドインフラリソースの変更を行っています。 今回は、Terraform Google ProviderのCloud Schedulerが毎回replaceされてしまう問題を解決した話をご紹介します。

f:id:k-yomo:20210120030130p:plain
Terraformロゴ

  • Cloud Schedulerがreplaceされてしまう問題
  • Terrafromの構成
  • Cloud Schedulerの更新をサポートする
  • まとめ
  • We're hiring
続きを読む

GCS bucketの利用量をSlackに通知する

この記事はエムスリー SRE がお届けするブログリレーの5日目です。

エムスリーエンジニアリンググループ AI・機械学習チームの笹川です。 趣味はバスケと、筋トレで、このところはNBAがてんやわんやしているのを楽しんでいます (Brooklynの今後の状況が特に気になっています)。

今回は、GCSバケットの利用量を監視して、Slackに通知するジョブを作ったので、その背景と、利用した技術の構成について説明します。

f:id:hsasakawa:20210118162714j:plain
ベッドの下で得意げにこっちを見る犬氏 (かわいい)

  • GCSの利用量を通知する背景
  • 技術構成
  • まとめ
  • We are hiring!
続きを読む

Terraformの謎のdiffと戦っている話

この記事はエムスリー SRE がお届けするブログリレーの4日目です。

こんにちは。マルチデバイスチームでチーム内SREを担当している大和です。 普段はアプリ向けのAPIサーバについてJava/KotlinおよびTerraformでアプリとインフラを構築しています。

Terraformあるあるだと思うのですが、ときどき意図しないdiffが出てきてドキドキすることがあります。 今回は解決のために terraform-provider-aws のコードを読んでdiffが出てきた原因を確認した例について、簡単に紹介したいと思います。

(チーム内SREについては次の記事に説明があります: SREの民主化とクラウド移行 - エムスリーテックブログ)

f:id:daiwa_home:20210115151049p:plain
謎のdiffと戦うエンジニアのイメージ (画像を提供していただいた山本さんの記事はこちら: SREを麻雀に例えたら(哭き派とメンチン派の争い) - エムスリーテックブログ)

続きを読む

エムスリーでのクラウド費用監視

こんにちは!エンジニアリンググループ、コア SRE の平岡です。

この記事はエムスリー SRE がお届けするブログリレーの3日目です。

エムスリーでは現在、クラウドプラットフォームとして AWS と GCP を採用しています。プロダクトを開発している各チームには、そのプロダクトを適切に実装できるプラットフォームを自由に選んでもらっています。

そんな中、エムスリーではここ数年、 SRE の役割をプロダクト開発チームに分散・移譲する取り組みを進めています(リレーの前記事にあった「チームSRE」の体制づくりです)。その結果、プロダクトの開発に伴うインフラ構築・管理のほとんどが各チームに一任されるようになっています。

というわけでこの記事では、エムスリーでチームSREの体制づくりを推進する中での、クラウド利用における費用監視の仕組みについてご紹介します。

f:id:uhm3:20210113044732j:plain
中で何かが起きてそうな雲・・・

続きを読む

Kaggle "Mechanisms of Action (MoA) Prediction" に参加し4位に入賞した話

はじめまして。 エムスリーエンジニアリンググループ/AIチーム 堀江です。

今回、データ分析コンペティションプラットフォームであるKaggleにて、2020年9月 ~ 2020年12月まで開催されていた Mechanisms of Action (MoA) Prediction に参加し、私を含む "Kanna Hashimoto with Friends" というチームで4373チーム中4位に入賞することが出来ました
(同時に、念願のgoldメダル取得でKaggle Competitions Masterになりました e-mon | Kaggle )。

f:id:eemon18:20210108201258p:plain
Private LBの結果

そこで今回は、参加記録をかねて、Code Competitionの取り組み方について紹介させていただきたいと思います。 本記事では主に、CodeComptitionとはなにか、どのように今回取り組んだのかについて紹介するため、 解法の詳細や、コード等は以下の記事をご覧ください。

4th Place Solution in Mechanisms of Action (MoA) Prediction

www.kaggle.com

github.com

続きを読む

SREを麻雀に例えたら(哭き派とメンチン派の争い)

エムスリーエンジニアリンググループSREチームの山本です。

私はエムスリーに入社してまだ1年少しなのですが、前職でも似たような職務を担当していました。

その中で、実は「インフラのあり方」には二大潮流が存在し、その中で皆が苦しみもがいているのではないだろうか?と感じました。前職や現職で感じたアレコレをエッセーのように軽い読み物にしますので、SREブログリレー二日目のネタとして書かせてください

なお、文字だけでは書きたいことが足りぬため、私が直々に画伯として挿絵も描いてしまいます。 ちなみに「麻雀に例えたら」と書きましたが、実は私は麻雀のルールをほとんどしりません。某有名麻雀劇画の作者はルールを知らないのに勢いで麻雀を描いたようですし、私もそれでいきたいと思います。

続きを読む

SREの民主化とクラウド移行

あけましておめでとうございます。今日から02/05までの平日にエムスリーのSREでブログリレーを開催します。その初日の投稿を担当させていただくエムスリーエンジニアリンググループの岩佐です。グループリーダーという立場でSREチーム、基盤チーム、セキュリティチーム、Unit4(m3.com/サイトプロモ)を担当しています。

私からはエムスリーでSREを拡大しようと推進している経緯/流れについて一筆認めさせていただこうかと思います。

  • 要約、早速だけど
  • 経緯、メンバーに敬意を、チームに契機を
  • 方針、状況に合わせて更新
  • 計画、そして軽快に改革
  • まとめ、ちょっとまともに

要約、早速だけど

  • SREを短期的に大量に採用するのは不可能、じゃないかのう?
  • オンプレミス環境で拡大していくサービス群をSREチームのみが運用していくのは難しい。こんなん困難では?はー、どうしよう
  • 権限の移譲、DevOpsの推進をするのがよさそう、以上。まだ続くけど
  • そのためにクラウド移行していこうという段階
  • SREの採用戦略も変更

最後に持ってきて『ようやく要約です』もありでした。

続きを読む