エムスリーテックブログ

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

Chaos-Monkey ならぬ Cosmos-Monkey で AWS 費用に秩序をもたらした話

こんにちは、エムスリー ソフトウェアエンジニア 兼 QLife チーフアーキテクトの園田 (@ryoryoryohei) です。

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

Cosmos-Monkey とは

エムスリーグループの QLife では toC のサービスを AWS で運用しています。それらは (当然ですが) 本番環境とは別に開発環境や QA 環境を持っています。

QLife に限らずほとんどの組織で同様だと思いますが、開発環境や QA 環境においては必ずしもサービスが 24 時間稼働である必要はないと思います。

そのため、QLife では 2019 年*1から稼働時間外の EC2 や RDS を停止する仕組みを Lambda 関数で実装し、導入していました。

今回はその仕組みを Golang から TypeScript に移植*2して、さらに Public に公開したのでその紹介をしたいと思います。

*1:QLife で AWS を利用しはじめたのは 2018 年末

*2:Node + TypeScript の並行処理の書きやすさから再実装しました

続きを読む

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ブログリレー二日目のネタとして書かせてください

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

続きを読む