エムスリーテックブログ

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

担当マイクロサービスのSLI/SLOを見直そうと思ったんだ

エムスリーエンジニアリンググループの関根(@sekikatsu36)です。 この記事はエムスリーSREがお届けするブログリレーの14日目です。

今回、私のチームが担当しているサービスのSLI/SLOを見直すこととなり、あらためて「マイクロサービスのSLI/SLOとは」を自分なりに考える機会ができたため、その話を紹介したいと思います。 まだ実行中で結論は出ておらず、内部でも議論の余地があるものですが、何かご参考になる点があれば幸いです。

続きを読む

AWS上の旧インフラをVPC移行した話

こんにちは、エンジニアリンググループ AI・機械学習チームの安田です。最近rustでTCP/IPスタックを作って遊んでます。

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

今回は先日実施した、AWS上でVPCの異なる環境へインフラ移行をした話をします。

その中で、

  • ほとんど同じ名前のリソースの移行
  • MLのモデル等大きなデータを移行
  • AWSアカウントの違うシステムでの短い停止時間でのシステム移行

の点に注力したのでご紹介します。

押さえるべきポイント

本記事でお伝えしたい、移行時に引っ掛かりそうなポイントです。

  • ほとんどのリソースはAWSアカウントユニークだが、S3はAWS全体でユニーク
  • NSレコードのTTLは長い
  • Route53のALBのAレコードは、サジェストされない値を直接書き込める
  • ACMはRoute53での証明書発行時、CNAMEレコードを参照するがAレコードは不要
  • 押さえるべきポイント
  • 背景
  • 実施概要
    • 現状説明
    • 今回の変更
  • 移行のポイント1: ほとんど同じ名前のリソースの移行
  • 移行のポイント2: MLのモデル等大きなデータを移行
    • S3のMLモデル移行
    • RDSのデータ移行
  • 移行のポイント3: AWSアカウントの違うシステムでの短い停止時間でのシステム移行
    • AWSアカウント間でRoute53を移行しないといけない
    • ALB・ACMがRoute53と依存関係にある
  • まとめ
  • We are hiring!
続きを読む

データベース移行でやらかした話

はじめに

こんにちは。エムスリー エンジニアリンググループの高島(id:rst76)です。

この記事はエムスリー SRE がお届けするブログリレーの 12 日目です。 ブログリレーに何を書こうかと悩んでいたのですが、つい先日、データベースを移行する際に障害を起こしてしまったので、その話をしたいと思います。 人の失敗談は面白い学ぶところが多いので…

続きを読む

インフラの実務経験ゼロからSREにチャレンジした1年弱を振り返る

こんにちは、エムスリー エンジニアリンググループ / 製薬企業向けプラットフォームチームの後藤です。

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

このブログリレーでも何度か紹介していますが、エムスリーにはチーム横断のSREである「コアSRE」と各サービスチーム内のSREである「チームSRE」が存在します。
私は2020年4月にチームSREとして入社しましたが、それまで実務としてインフラをしっかりと触った経験はほぼゼロでした。

本記事では、このような私がチームSREとして1年間どのような業務に取り組んできたのか紹介したいと思います。
今はSREではないけれども、SREに興味がある、チャレンジしてみたいと思っている方々の参考になればと思います。

続きを読む

誰も知らないインフラコンポーネントをそっとコード化した話

「え、なにこれ。うち、 memcached なんて使ってたっけ……」

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


エムスリー SRE がお届けするブログリレーの 10 日目。エンジニアリンググループ / 電子カルテチームの山口 (@no_clock) です。

入社直後はサーバサイドメインのソフトウェアエンジニアでした。 SREの民主化とクラウド移行にある民主化の流れに「やってみたいです〜」と宣言し、 1 年半前から電子カルテチーム内の SRE も兼任しています。

今回は、「兼任」が功を奏して謎のインフラコンポーネントをコード化できた話です。

  • 知っている人が誰もいない状態
  • 「memcached サーバ……?」
  • Terraform で管理されていない、システム構成図にもない
  • 利用されているか、 Web アプリケーションのコードを確認する
  • 適切に IaC にするために、やはりコードを確認する
  • 振り返り: 同じ過ちを繰り返さないために
    • 原因: なぜ起きたか
    • 改善策: 繰り返さないために何ができるか
  • まとめ: 「チーム内 SRE」は面白い
  • We're hiring! チーム内 SRE 、どうでっか?
続きを読む

Trusted Advisorを利用してAWS利用の改善を進めていく話

こんにちは、エムスリー 株式会社 エンジニアリンググループ コアSREの笠井です。

この記事はエムスリーSREがお届けするブログリレーの9日目です。 エムスリーではここ数年、 SRE の役割をプロダクト開発チームに分散・移譲する取り組みを進めています(リレーの前記事にあった「チームSRE」の体制づくりです)。

その結果、プロダクトの開発に伴うインフラ構築・管理のほとんどが各チームに一任されるようになっています。

この記事では、エムスリー でAWS Trusted Advisorを利用し、各チームが行うAWSアカウント利用の改善を進めていったことについてお話ししようと思います。

続きを読む

チームSRE立ち上げ期にやってみて良かったこと

こんにちは、エムスリー エンジニアリンググループ / 製薬企業向けプラットフォームチームの鳥山 (@to_lz1)です。

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

このブログリレーで複数回言及されているように、エムスリーでは昨年から大々的に「チームSRE」という制度を導入しています。従来からのSREすなわち「コアSRE」が受け持っていた業務や権限を、各プロダクトチーム内のSREすなわち「チームSRE」に委譲している真っ最中です。

私の所属する製薬企業向けプラットフォームチーム(Unit1と呼ばれています)のチームSREの導入タイムラインは、以下のような感じです。

  • 2020年4月に最初のチームSREが入社
  • 2020年7月ごろに私を含む6名がチームSREとして追加
  • 複数サービスのクラウド移行を実施しつつ今に至る

したがって、少なくとも私のチームではこの「チームSRE」という取り組みは始まって1年足らず、まだまだ立ち上げ期と呼んで良いかと思います。

今回は、そんなフェーズの中でチームSREとしてやってみたこと、やって良かったと感じたことをいくつかご紹介します。

  • 1. Terraformリポジトリの一元化
    • 統一して起きた素敵なこと
    • CIの共通化
    • 「ちょっとしたソリューション」を試しやすい
  • 2. 移行作業の「Zoom中継」
    • 中継して起きた素敵なこと
  • まとめ: コロナ禍でも「コラボレーション」を諦めない
  • We are Hiring!

f:id:to_lz1:20210121002103j:plain
何かを立ち上げるには大規模な工事が必要になる...ときもあります

続きを読む