SRE NEXT 2024 登壇&参加レポート その1 - エムスリーテックブログ
こんにちは、SREチームの後藤です。 8月3日と4日の2日間、Abema Towersで開催されたSRE NEXT 2024にて登壇させて頂きました。 こちらに、自身の登壇についての話と印象に残ったセッションなど参加レポートとしてご紹介させて頂きます。 正答率80%でギリギリゲットした信頼性カレー SRE NEXT 2024について 自分の登壇について 印象に残ったセッション 組織的なインシデント対応を目指して〜成熟度評価と改善のステップ〜 プロダクトのスケールによって顕在化しうるリスクをどう管理するか？ 事業フェーズの変化を乗り越えるEnabling/Platform SREへの転換 まとめ We are Hiring! SRE NEXT 2024について 今年は、「Beyond NEXT」というテーマで2日間、オンラインとオフラインのハイブリッド開催でした。 私は両日とも現地で参加させ
コアSREチームからサービスチーム側に落下傘してみてた話 - エムスリーテックブログ
皆さんこんにちは、エンジニアリンググループの高橋(@tshohe1)です。 この記事はエムスリーSREがお届けするブログリレーの15日目です。 他の記事でも何度か説明されていますが、エムスリーでは2019年頃からチーム横断的なシステムを管理する「コアSRE」とは別に、サービスチーム内にて各サービスのインフラを重点的に見る「チームSRE」というポジションを新たに設けています（チームSRE化の流れの詳細については下記ブログリレー最初の記事*1を御覧ください）。 私は入社時点ではコアSRE（当時はまだインフラチーム*2）として働いていましたが、2019年頃からサービスチーム側SREと兼務したりコアSREに戻ったりまたチーム側SREに移動したりとふらふらしている謎の存在になっていました。 現時点ではコア/チーム側両方に所属していた者はいないはずなので、本記事ではコアSRE側の視点/チームSRE側の
PostgreSQL チューニングよもやま話 - エムスリーテックブログ
【Unit4 ブログリレー3日目】 こんにちは，エムスリーエンジニアリンググループの榎田です．数学とテレビゲームが好きです． 今回は，Unit4 で運用している "Docpedia" というサービスで実施した SQL チューニングの実例を2つご紹介します．普段の私が意識していなかった， RDBMS の内部機構に関する話が登場して面白かったので，今回の記事を書きました． なお，本稿で扱う議論はすべて PostgreSQL 11.x 以上を対象としており，特にその他の RDBMS で同様の動作をするかは確認していません．定性的な挙動に共通するものはあるかもしれませんが，ここで述べた話はそのままは通らないであろうことをお断りさせてください*1． プロダクトについて index なしで意外と耐えたが，耐えきれなかった話 実際の SQL とテーブル定義 原因の分析 対応策 SELECT DISTIN
なんとなくで終わらせない、言語化すると見えてくる障害調査の5つのポイント - エムスリーテックブログ
【SREチーム ブログリレー4回目】 こんにちは、SREチームの後藤です。 障害が発生した時、魔法のように原因を特定し颯爽と解決していくスーパーな同僚は皆様の周りにもいませんか? その姿に憧れてそうなりたいと思ったことが誰しも一度はあるはず。 ですが、話を聞いてみると「なんとなく怪しそうだった」「勘でここかなと思った」と言われたりして、まったく参考にならなかったこともあるのではないでしょうか。 そこで今回は私が考える障害調査において意識すべきポイントを、なんとなくではなくしっかりと言語化してまとめたいと思います。 題して「なんとなくで終わらせない、言語化すると見えてくる障害調査の5つのポイント」 神頼みしたくなる時も挫けずに強い心を持つことも大事 1. 調査できるように備えておく 2. 事象を正確に把握する 3. 事実と推測を区別する 4. 先入観を排除する 5. 問題を局所化する まとめ
AWS Advanced JDBC WrapperによるAurora Postgresの高速フェイルオーバー - エムスリーテックブログ
【 デジスマチーム ブログリレー1日目】 こんにちは。 デジスマチームの山本です。 クリニック向けDXサービスであるデジスマ診療のWeb フロントエンド・バックエンド・インフラを担当しています。 今回は先日AWSから発表されたaws-advanced-jdbc-wrapperについて紹介します。 はじめに AWS Advanced JDBC Wrapper 提供Plugin フェイルオーバーとは これまでのフェイルオーバー対策 AWS Advanced JDBC Wrapperを利用した場合のフェイルオーバー対策 Failover Connection Plugin Host Monitoring Connection Plugin 導入方法 Gradle(Kotlin)での依存先の追加 Spring Boot + HikariCPでの設定例 実際に動かしてみた 何も設定しない場合 設定後
担当マイクロサービスのSLI/SLOを見直そうと思ったんだ - エムスリーテックブログ
エムスリーエンジニアリンググループの関根（@sekikatsu36）です。 この記事はエムスリーSREがお届けするブログリレーの14日目です。 今回、私のチームが担当しているサービスのSLI/SLOを見直すこととなり、あらためて「マイクロサービスのSLI/SLOとは」を自分なりに考える機会ができたため、その話を紹介したいと思います。 まだ実行中で結論は出ておらず、内部でも議論の余地があるものですが、何かご参考になる点があれば幸いです。 事の発端 ビジネスサイドとの対話 方針転換 終わりに We are Hiring! エムスリーでは数百のマイクロサービスを開発・運用していますが、今回は私の所属チームで担当している「医療ニュースの管理サービス」を取り上げます。 このサービスは、ニュース記事を表示するWebページ、ニュース記事を登録・取得するAPI、リコメンドやメルマガのための記事情報を分析・
チームSRE立ち上げ期にやってみて良かったこと - エムスリーテックブログ
こんにちは、エムスリー エンジニアリンググループ / 製薬企業向けプラットフォームチームの鳥山 (@to_lz1)です。 この記事はエムスリーSREがお届けするブログリレーの8日目です。 このブログリレーで複数回言及されているように、エムスリーでは昨年から大々的に「チームSRE」という制度を導入しています。従来からのSREすなわち「コアSRE」が受け持っていた業務や権限を、各プロダクトチーム内のSREすなわち「チームSRE」に委譲している真っ最中です。 私の所属する製薬企業向けプラットフォームチーム（Unit1と呼ばれています）のチームSREの導入タイムラインは、以下のような感じです。 2020年4月に最初のチームSREが入社 2020年7月ごろに私を含む6名がチームSREとして追加 複数サービスのクラウド移行を実施しつつ今に至る したがって、少なくとも私のチームではこの「チームSRE」と
SREを麻雀に例えたら(哭き派とメンチン派の争い) - エムスリーテックブログ
エムスリーエンジニアリンググループSREチームの山本です。 私はエムスリーに入社してまだ1年少しなのですが、前職でも似たような職務を担当していました。 その中で、実は「インフラのあり方」には二大潮流が存在し、その中で皆が苦しみもがいているのではないだろうか？と感じました。前職や現職で感じたアレコレをエッセーのように軽い読み物にしますので、SREブログリレー二日目のネタとして書かせてください なお、文字だけでは書きたいことが足りぬため、私が直々に画伯として挿絵も描いてしまいます。 ちなみに「麻雀に例えたら」と書きましたが、実は私は麻雀のルールをほとんどしりません。某有名麻雀劇画の作者はルールを知らないのに勢いで麻雀を描いたようですし、私もそれでいきたいと思います。 ロン！クラウド無双！！ 二種の潮流 哭きのSRE メンチン型SRE どちらが正しいのか？ SREとしての立場と技術選定 「シクヨ
SREの民主化とクラウド移行 - エムスリーテックブログ
あけましておめでとうございます。今日から02/05までの平日にエムスリーのSREでブログリレーを開催します。その初日の投稿を担当させていただくエムスリーエンジニアリンググループの岩佐です。グループリーダーという立場でSREチーム、基盤チーム、セキュリティチーム、Unit4(m3.com/サイトプロモ)を担当しています。 私からはエムスリーでSREを拡大しようと推進している経緯/流れについて一筆認めさせていただこうかと思います。 要約、早速だけど 経緯、メンバーに敬意を、チームに契機を 方針、状況に合わせて更新 計画、そして軽快に改革 まとめ、ちょっとまともに 要約、早速だけど SREを短期的に大量に採用するのは不可能、じゃないかのう？ オンプレミス環境で拡大していくサービス群をSREチームのみが運用していくのは難しい。こんなん困難では？はー、どうしよう 権限の移譲、DevOpsの推進をする
Jenkinsをエンジニアでない人も使えるDigdagのWeb UIとして使う - エムスリーテックブログ
こんにちは、エンジニアリンググループの福林 (@fukubaya) です。 現在、弊社では長年運用され続けているレポート基盤のリニューアルを昨年から続けています。 その一環で、エンジニアでない人も使えるレポート生成UIを実現するため、 DigdagとJenkinsを利用した仕組みを検討しました。 本記事ではその一例をご紹介します。 横浜赤レンガ倉庫は横浜港にある歴史的建築物。本文には特に関係ありません。 レポート生成UIとしてのJenkins 弊社では、客観的なデータに基づき意志決定することがエンジニアに限らず基本となっているため、 あらゆるサービスでデータの蓄積、分析、活用が日常的に行われています。 レポート生成処理は基本的にはスクリプト実行なので、実行もコマンド実行になりますが、 エンジニアでない人にコマンド実行でレポートを生成してもらうのは難しいです。 そこで、弊社ではJenkins
(小ネタ) AutoScaling で増減した EC2 インスタンスに動的に CloudWatch Alarm を設定 - エムスリーテックブログ
こんにちは、エムスリーエンジニアの園田です。 AWS の AutoScaling で増減する EC2 インスタンスに対して CloudWatch Alarm を動的に設定したくなることありますよね？ AutoScalingGroup のメトリクスで AutoScalingGroup 内の平均 CPU 利用率などを監視することはできますが、 個々のインスタンスそれぞれに対してアラームを設定することは（今のところ）できません。 正確には、設定したとしても AutoScaling で新しく起動したインスタンスには設定されませんし、 スケールインで削除されたからといって自動でアラームの設定が削除されることもありません。 そこで、 CloudWatch Event Rule と Lambda を使って増減するインスタンスに対して動的にアラームを設定するのを試してみました。（何番煎じかわかりませんが・
SRE Lounge #9 で弊社の取り組みについて話しました - エムスリーテックブログ
こんにちは、エンジニアリンググループ SREチームの高橋(@tshohe1)です。 5/29に開催されたSRE Loungeというイベントで「エムスリーはどのようにしてSREをはじめたか」というタイトルで登壇させていただきました！ 登壇の場を提供していただいたSRE Lounge運営スタッフの方々、スポンサー＆会場提供していただいたサイバーエージェントさん、ありがとうございました。 本記事ではイベントの簡単なまとめと、時間の都合上語れなかった弊社の他の取り組みを少し書いていきたいと思います。 ANA Lounge Haneda by LWYang is licensed under CC BY 2.0 SRE Lounge について 各社のSRE実践例などが聞けるイベントです！ イベントページ sre-lounge.connpass.com 今回のページ（第9回） sre-lounge.c
「入門 監視」を読んで見えてきた現状の課題と改善点 - エムスリーテックブログ
こんにちは、エンジニアリンググループ SREチームの高橋(@tshohe1)です。 「入門 監視」という本が各所で話題になっていますが、エムスリーのエンジニアリンググループでも予約購入していました！ www.oreilly.co.jp 監視というSREと非常に親和性の高いテーマの本だったこともあり、多くのSREメンバがこの本に目を通していたようです。 そこでぜひチーム内で感想を共有しようということになり、先日感想共有会が実施されました。 本記事ではそのときに挙がった感想を一部抜粋して公開したいと思います。 モニターリザード 各章の感想 「1章 監視のアンチパターン」について 「第2章 監視のデザインパターン」について 「3章 アラート、オンコール、インシデント管理」について 「5章 ビジネスを監視する」について 「6章 フロントエンド監視」について 「7章 アプリケーション監視」について
AWS Fargateのデプロイパイプライン(Gitlab > S3 > CodePipeline)を構築してみた - エムスリーテックブログ
こんにちは、エムスリーエンジニアの園田です。 この記事はAWS FargateでElixirのコンテンツ配信システムを動かしてみた (実装編) - エムスリーテックブログの続きです。 エムスリーでは医療・ヘルスケアサイト向けのコンテンツ配信システムであるChuoiというサービスを運用しています。先日のポストで、ElasticBeanstalkからFargateに運用を切り替えたことについて書きました。 www.m3tech.blog 今回は前回に引き続きその実装編で、CodePipeline を利用したデプロイパイプラインの構築について書きます。 まずは構成のおさらいです。 デプロイ周りは以下のような構成です。 社内 Gitlab からの CI/CD パイプライン構築 先日の記事で述べたとおり、弊社ではソース管理にオンプレの Gitlab を使っており、 CodeBuild や CodeP
DatadogでDocker監視が幸せになった話
こんにちは、エンジニアリングGの安田(@dasoran2)です。7月に入社してAI・機械学習チームに所属しています。趣味は猫耳で入社早々会社では猫耳エンジニアとしての地位を確立しつつあります。 今回は転職早々ではあるものの、自分のチームでDatadogをトライアル導入したのでその話を書きます。 本稿は以下のような内容をお話しします。 Datadogを選んだ理由 DatadogでのDocker監視の概要 Datadogでハマったところ *1 事の発端 チーム内でレスポンスタイムに問題が発生して、その原因を調査する機会がありました。 しかし、メトリクスがCloudWatchで収集されているもののほかになく、それ以上を取るにはインスタンスやコンテナの中に入って収集する必要がありました。そのため、迅速な対応ができずこの状況を打破したいと考え各種導入検討を開始しました。 Datadogを選んだ理由
AWS FargateでElixirのコンテンツ配信システムを動かしてみた (実装編) - エムスリーテックブログ
こんにちは、エムスリーエンジニアの園田です。 この記事は先日のAWS FargateでElixirのコンテンツ配信システムを本番運用してみた - エムスリーテックブログの続きです。 エムスリーでは医療・ヘルスケアサイト向けのコンテンツ配信システムであるChuoiというサービスを運用しています。先日のポストで、ElasticBeanstalkからFargateに運用を切り替えたことについて書きました。 www.m3tech.blog 今回はその実装編で、実際のコードを見ながら説明します。 まずは構成のおさらいです。 Fargate化のためにやったこと AWS Fargateで運用するために実際にやった作業は大まかに以下の通りです。 Elixir/PhoenixアプリのDocker化 Docker化したアプリのFargate動作確認 社内GitlabからのCI/CDパイプライン構築 Terra
AWS FargateでElixirのコンテンツ配信システムを本番運用してみた - エムスリーテックブログ
こんにちは、エムスリーエンジニアの園田です。 エムスリーでは医療・ヘルスケアサイト向けのコンテンツ配信システムであるChuoiというサービスを運用しています。 以前このブログでも紹介しましたが、このサービスは Elixir/Phoenix で実装されていて、ElasticBeanstalk のCustom Platformを使って運用していました。 www.m3tech.blog 2018/07/04 に AWS Fargate が東京リージョンでローンチされたので、ElasticBeanstalk から Fargate での運用に切り替えました (2018/07/13 切り替え完了)。その際の手順やTipsを書きたいと思います。 今回は構成の説明のみで、実際のコードなどは別のポストで解説していきます。 2018/07/30 追記 実装編の記事を書きました。 www.m3tech.blog
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
