はじめにTechnology Innovation Groupの八木です。 フューチャー社内の有志メンバーでログ設計ガイドラインを作成し公開しました！ ログは、システムの稼働状況を可視化し、トラブルが発生した際に迅速に原因特定するための生命線になります。しかし、その重要性の一方で、プロジェクトごとに設計がバラバラになりがちだったり、とりあえず標準出力しているだけになっていたりと、十分に活用しきれていないケースも多く見受けられます。 本記事では、今回公開したログ設計ガイドラインの背景や、現場で役立つ設計のポイントを抜粋してご紹介します。 ガイドライン作成のモチベーションこれまで、ログ設計は個々のエンジニアの経験則や、プロジェクトごとの慣習に委ねられることが多くありました。しかし、システムが複雑化し、マイクロサービスやクラウドネイティブな構成が当たり前になった現代において、ログの役割は「単なる
はじめに 先日、下記のようなツイートを見つけて、そういえば趣味で個人開発してたときには然程気にしてなかったけど、仕事で運用するようになって先輩たちから学んだり自分で身につけたチップスってちょこちょこあるよねー、とふと思ったので、Webアプリケーション開発に関わるものをいくつかまとめてみました。 特に体系的/網羅的という程でもないですし、最近はFWや色々な仕組みでカバーされてるものも多いですが備忘録として。 Tips 機械が読めるログを作る これは割と重要なのですが、ログは人間が読むものではなく機械が読むものです。それはZabbixだったりDatadogだったりSplunkだったりgrep/awkだったりツールは何でも良いのですが、古の時代はさておき現代ではログは機械が読めることが最重要です。 まず大前提として構造化されている必要があります。言うまでもないですが「フリーフォーマット」のログの
PyCon JP 2021 発表資料です。
Observabilityを理解するため、目先としてはDatadogを使いこなすため、統計学の基礎知識を振り返りつつ、Datadogの各機能に触れます。 Datadogの使い方を具体的に知りたい人には役立たないので、その仕様がなぜそうなっているのか、背景や違いを理解したい人向け。モニタリング機能は統計学の実装とも言える、という個人的見解が今回の動機です。 Observabilityとは システム内で「あの時どこで何が起きていたか」を知る能力。和訳では可観測性。 単なる監視だけでなく、分散トレーシング、プロファイリング(性能評価)、デバッグも含まれています。 個人的印象としては、分散トレーシングと一緒の文脈でObservabilityの重要性を言われることが多く、分散システムが流行り始めた頃と同時期に必要とされた非機能要件かと感じてます。 統計学の尺度とデータ Datadogで扱うデータを理
この記事は Money Forward Engineering 2 Advent Calendar 2022 18日目の投稿です。 こんにちは。マネーフォワード関西開発拠点でマネーフォワード クラウド会計Plus (以下会計Plus)のエンジニアをしているぽっけです。 この記事では、私が行った高速化について紹介します。 私は最近Railsアプリケーションの高速化を行っており、ある画面のレスポンスタイムを50%以上削減しました。そしてこの改善はRubyレベルの変更のみで達成しました。 この記事での「Rubyレベルの変更のみ」は、MySQLやRedis、Web APIなどへのアクセスには全く手を入れず、Rubyのプロセスが消費する時間のみを変更した、ということを意図しています。 MySQLなどへのアクセスは通常ボトルネックになりがちな箇所です。今回そこに手を入れずに高速化を達成できたのは、1つ
こんにちは。中山(id:yoichi22) です Software Designに連載させていただいております「Pythonモダン化計画」では、モノタロウの社内事例から読者の皆様のお役に立ちそうな取り組みを紹介させていただいています。のですが、社内でも隣のチームがやってた取り組みを記事で初めて知ることもあって、私も読者として楽しませてもらっています。隣の執筆者さんありがとうございます。 今回は、運用にまつわる監視とログの話題です。本記事の初出は、Software Design2022年1月号「Pythonモダン化計画（第6回）」になります。過去の連載記事は以下を参照ください。 第1回 Software Design連載 2021年8月号 Python製のレガシー＆大規模システムをどうリファクタリングするか 第2回 Software Design連載 2021年9月号 「テストが無い」からの
Datadog はモニタリング関連の SaaS ではおそらく最も利用されているサービスでしょうが、公式ドキュメントが豊富にある割には何から読み始めれば良いかわかりにくく、慣れるまでの道が険しい印象です。 本エントリーでは、Datadog が既に導入されている組織で、Datadog モニターを使って監視をしたいけど、モニターの設定方法がよくわからないといった方を対象に、メトリクスモニターの作成に焦点を絞って解説していきます。なお、あくまで Datadog の使い方についての解説であり、どのようなモニターを設定すべきかについては触れません。 メトリクスの収集についても触れたかったんですが、力尽きたので、メトリクスの収集については気が向いたら別エントリーを書きます。 アジェンダ メトリクスモニターの作成方法の基本 クエリの定義について クエリの評価期間・評価方法・アラート条件の指定 クエリの結果
こんにちは、freee会計でワークフロー機能の開発をしている @mitubaEX です。 先日 freee会計のパフォーマンスチューニングに取り組みました。本記事では、調査の流れ、改善の事例を紹介します。 問題発覚までの流れ freee では自社の経理業務に freee会計を利用しており、その中でも経費精算の機能はほぼすべての従業員が利用しています。そのため日々多くのフィードバックをもらえます。そのフィードバックの1つで、「経費精算の一覧を開くのが遅い」という報告をもらいました。幸い表示件数を指定できるので調整すれば遅くはならないのですが、一覧性が下がってしまうため有用な解決策ではありません。 そこでワークフローを開発しているチームで、このパフォーマンスイシューの調査を始めました。 調査する まず事前調査として Datadog*1 で一覧画面を表示するリクエストの処理を確認しました。 一覧
ゆるSRE勉強会 #1 でお話しさせて頂いたLTの資料です！ https://yuru-sre.connpass.com/event/292063/
不正アクセスの中でも、アカウントへの不正ログインはもっとも基本的な攻撃になります。 なぜならログイン画面はどのサービスでも公開されていることが多く、 最近は外部サイトから流出したパスワードリストを使ったCredential Stuffingといった攻撃も行われます。 そのため、アカウントへの不正ログインは、攻撃者にとってはどのサイトでも共通の攻撃ができる比較的安易な攻撃方法となります。 この問題への根本的な対策は難しいですが、KARTEでも実装している多要素認証やアカウントロック機能といった対応が考えられます。 一方で、このような攻撃が実際に行われているかを監視する仕組みは、直接的な対策とは別途必要になります。 なぜなら、対策に抜け道がある可能性や外的要因で攻撃が突発的に発生する可能性があり、それに気付く仕組みと組み合わせることが重要となるためです。 KARTEではログのモニタリングにDa
freee人事労務の品質改善を専任で活動している keik です。 freeeではアプリケーションパフォーマンスモニタリング（APM）に Datadog を利用しています。 SRE チームが導入し、アプリケーション開発チームに利用提供する形で運用されています。 導入のきっかけについては以下の記事でも触れられています。 developers.freee.co.jp Datadog APM の画面は多機能かつ柔軟で、例えばウェブサーバーが受けたリクエスト処理の内訳を視覚的にドリルダウンできたり、リクエストや SQL クエリごとのレイテンシやエラー率を計測してダッシュボード化してくれたり、また全画面で共通的に「タグ」や日時を用いたフィルタリングができたりします。直感的なだけなく、見た目もオシャレで、適当に眺めているだけでもワクワクします。 しかし、私達は「ここに映っているもの」が何なのか、正直分
https://sre-lounge.connpass.com/event/227250/
tfnotify - Show Terraform execution plan beautifully on GitHub
デジタル時代の企業にとって、システムの安定稼働と迅速な問題解決は、競争力を維持するための重要な要素です。21社にご寄稿頂いた「Amazon CloudWatch」「Datadog」「Grafana」「New Relic」「Prometheus」「Sentry」「Splunk」の各ツールレビュー記事を参照・抜粋し、それぞれの企業がどのようにシステムの健全性を確保し、未来の課題に備えているのかをアーキテクチャを通してご紹介します。 ※ツール名・ご寄稿企業名共にアルファベット順で掲載しております Amazon CloudWatchAWS CloudWatchは、AWSのクラウドリソースとアプリケーションの監視と管理を行うためのサービスです。メトリックス、ログ、イベントなどを収集、追跡し、可視化することで、システム全体の状態を把握し、問題の早期発見と解決をサポートします。 ▼Amazon Clou
必要性 フロントエンドの監視はバックエンドやインフラのそれらと比べ、優先度が低くなりがちです。 バックエンドやインフラでの障害はサービス継続に直結するため、これは当然と言えば当然なのですが、別の理由もあると考えています。 それは計算リソースをサービス提供側が管理していないことです。 例えばアプリケーションがインフラとして AWS を利用しているなら、AWS のリソースを管理するのはサービス提供側です。 これは AWS 以外のクラウドサービスプロバイダやオンプレであっても同様です。 一方でフロントエンドはエンドユーザのブラウザ上で動作し、これを管理しているのはエンドユーザです。 フロントエンドはその性質上、監視の「盲点」になりがちです。 しかしフロントエンドはエンドユーザが直接触れるものであるため、そこで何が起きているかサービス提供側は正確に把握する必要があります。 マイルストーン フロント
こんにちは！広告事業本部でユニットマネージャーをやっている上森です。 本記事では、Datadog から CloudWatch への移行によって、月額$300から$40に、約87％のコスト削減に成功した話をご紹介します。 また、外形監視の手段選定に悩んでいる方、現在の監視コストを抑えたい方に向けて、CloudWatch Synthetics というコスパに優れた選択肢をお伝えしようと思います。 背景 私のチームでは直近でサービス運用コストの削減に注力しており、EC2, RDS のスペック適正化や Staging 環境の起動時間の見直しなど、多岐にわたる施策を実施してきました。 詳しい内容は同じチームの花田が執筆しましたので、そちらも合わせてぜひご覧ください。 そこで、これらの取り組みの一環として、普段あまり注目されない、監視ツールである Datadog の見直しを実施することになりました。
先日『フロントエンド監視の全体像と実現方法』という記事を投稿しましたが、その中でテレメトリについては触れませんでした（※本記事は上記記事の内容を知らなくても読み進められるようになっています）。 というのは、テレメトリは可観測性を実現するための重要な概念ではあるものの、テレメトリを軸に監視を考えるのは手段の目的化になってしまうと考えているからです。 重要なのはサービスにとって何を観測するべきかを考えることであり、テレメトリはそれを設計や実装に落とし込む際に現れるものです。 一方で監視に対する理解を深める上では、テレメトリを軸に考えることも重要でしょう。 そこで本記事ではフロントエンド監視においてどのようなテレメトリを収集するべきか述べていきます。 監視 SaaS と OpenTelemetry (OTel) Datadog, New Relic, Sentry のいずれかを利用することを考え
こんにちは。ECプラットフォーム基盤SREブロックの高塚と巣立（@tmrekk_）です。 ZOZOTOWNはクラウド化・マイクロサービス化を進める中で、監視SaaSのDatadogを採用しました。この数年で多くの知見が蓄積され、今では様々なシーンでDatadogを活用しています。この記事ではそのノウハウを惜しみなく公開します。 ※本記事は、先日開催されたDatadog Japan Meetup 2022 Summerにて発表した内容を書き起こして再構成したものです。 当日の発表資料 speakerdeck.com 目次 当日の発表資料 目次 はじめに マイクロサービス基盤に必要な監視の要件 第1部 ZOZOTOWNにおけるDatadogの活用 1. どこで障害が起こっているのか分からない → APM 2. アラートやダッシュボードや外形監視が欲しい → Monitors, Dashboar
はじめに 本記事では、Datadog の設定方法を解説しながら、どのようにフロントエンド開発に活用できるかを話していきます。Datadog とは SaaS 型で提供されている監視サービスです。システムやアプリケーションの監視ができ、収集したログを分析するのに役立つ機能をたくさん提供しています。 こんにちは、株式会社LegalOn Technologiesで Software Engineer（Frontend）をしている山越 ( @yukishinonomeIT ) です。弊社では2024年4月に『LegalOn Cloud』というプロダクトを提供開始しました。Datadog は既存のプロダクトでも使っていたので、この新しいプロダクトでも活用することになりました。そこで、『LegalOn Cloud』における Datadog の運用を担当することになったので、実際にどのような活用をしている
“爆速” 導入の舞台裏！デジタル庁が提供する「デジタル認証アプリ」の活用で実現「安全で簡単な本人確認システム」
これは Livesense Advent Calendar 2022 DAY 20 の記事です。 はじめに 株式会社リブセンスの転職会議事業部Webエンジニアの @ishitan-liv です。 今回は、過去に転職会議でも導入しようとして挫折してきたE2Eテストについて書きます。 E2Eテストを自作するか、SaaSを使うのかで比較した結果と、Datadog Synthetics Testsの使い方を軽く紹介したいと思います。 なお、この導入については完全に個人プロジェクトとしてやっております。 リブセンスではエンジニアの権利として毎月10%の技術投資枠確保というものがあり、Googleの20%ルールのようなもので、約20日勤務だと想定して2日間は興味のある技術的なことに使えます。 grow.google はじめに このブログ記事を読むと得られる(と思われる)もの 今回書かないこと 導入検討
はじめに システム要件を整理する際、次のような AWS の仕様を確認されたことはあるでしょうか。 パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。 これは「AWS のリソース間通信は、パブリック IP アドレスを使用した場合でもインターネットに出ない」ことを示しており、インターネット経由の通信を禁止したい要件にとってありがたい仕様といえます。 しかし、実際にその通信経路がどのように見えるのかを外部から確認することは簡単ではありません。 本記事では、Datadog の Network Path を利用し、E
AWSを活用するAutify、ZOZO、dipが、AWSコスト削減についての事例を発表するオンラインイベント「AWSコスト削減事例祭り」。3社それぞれが事例を発表しました。オーティファイ株式会社からは松浦隼人氏が登壇。同社における、AWSのコストの削減の事例について発表しました。 もともとはインフラを担当していた松浦隼人氏松浦隼人氏（以下、松浦）：オーティファイの松浦から、当社でのAWSのコストの削減の事例について発表したいと思います。よろしくお願いします。 今日のトピックは、タイトルのとおりですが、オーティファイでAWSのコストを見直すきっかけになったことと、その時の見直しの手法、それから当社にとってインパクトのあったコストの削減策について紹介したいと思います。 まず自己紹介からします。オーティファイの松浦と申します。今、機械学習とQAのチームのエンジニアリングマネージャーをしていますが
こんにちは、広告サービスを担当している飛田です。 今回は "SLO導入で悩んでいる方" に向けて、弊社リワード広告サービスでのSLO策定の取り組みについてお話したいと思います。 そもそもSLOを策定するに至った経緯は二つあります。 ユーザへの影響度合いが分かりづらいパフォーマンス問題などの対応が後回しにされがちで、品質改善がなかなか進まない アラート通知があってもユーザに影響があるか即座に判断できず、静観や一部アラートを無視する状況もあり、モニタリングが形骸化しつつある 両方とも共通してユーザに与える影響を正しく把握できていないことが課題のようです。 そこでSLOを策定する過程でオブザーバビリティを高め、モニタリングの最適化とエラーバジェット運用で開発リソース配分の状況改善を図りました。 一挙両得作戦です。 細かな取り組みは順を追って紹介します。 プロジェクト初期 ワークメトリクスからSL
はじめに こんにちは、SREチームの森原(@daichi_morihara)です。 今回はDatadogのログのコスト削減に関して最近行った取り組みを共有していきたいと思います。AWSやGCPなどのクラウドに関してはコスト削減・最適化に積極的に取り組んでいる一方で、Datadogに関してはあまりできていない、、というケースは多いのではないでしょうか？ (Datadogを使用している場合に限りますが。) 弊社でもDatadogのコスト最適化はあまり行えておらず、提供するサービスのスケールに伴ってDatadogのログコストが着々と増加してきたため、コスト削減に取り組むに至りました。 Datadogログコストの構造 Datadogのログコストは主に2つの要素によって構成されます。 ログの取り込み（Log Ingestion)：Datadogに送信されたログの収集・処理・パースするのに発生するコス
これは、とある僕のチームが運用しているWebアプリケーション (Go製) の、ヘルスチェック用エンドポイントの (リクエストハンドラーの) コードです。リクエストがきたら200 OKを返すだけの、シンプルな実装です。 func health(w http.ResponseWriter, _ *http.Request) { w.WriteHeader(http.StatusOK) } ところが、たったこれだけの処理しかしていないエンドポイントのレイテンシが、ある時からピーク時に著しく劣化するようになり、ひどい時には最大3.4秒もかかるようになってしまったのです。 なぜこのようなことになってしまっていたのか、またそれをどのように調査し、解決したのかについて解説します。 システム概要 今回問題となったWebアプリケーションはGoで書かれています。実行環境は Kubernetes (GKE) で
こんにちは。プロダクト本部プラットフォーム部SREチームのid:ut61zです。 サービスを運用していくうえで監視は避けて通れません。 Classiでは長らく朝当番という制度を設け、平日朝のピークタイムにエンジニアを監視担当としてアサインし、何らかの問題が発生した際、即座に対応できる体制を整えてきました。 2020年9月からスタートした朝当番制度ですが、2024年4月をもってこの制度を終了しました。 今回はその経緯や理由、現在のClassiの運用体制などをご紹介します。 朝当番とは あらためて朝当番制度とは、平日朝のピークタイムにエンジニアが常に1名待機し監視する制度になります。担当エンジニアは各種メトリクスに異常がないかチェックし、問題や気になったことがあれば関係各所に情報連携を行う役割を担います。 朝当番制度の目的、背景、期待される効果など、以下のブログに詳細が記載されていますので興味
これまで、Findy Toolsのアーキテクチャ特集記事では、テーマや分野ごとに複数の企業からアーキテクチャや技術選定の背景を伺い、まとめた記事をお届けしてきました。今回から始まる新シリーズでは、1社の技術選定についてさらに深く掘り下げ、個々の選択がどのように全体の成功に寄与しているのかをより詳細に探っていきたいと思います。初回の本記事では、まず私たち自身であるFindy Toolsが、2ヶ月という短期間でリリースに至った技術選定の裏側をご紹介します。 Findy Toolsについて Findy Toolsは開発ツールに特化したレビューサイトです。 ツールのレビューや他社のアーキテクチャを見て技術選定の参考にすることが出来ます。2024年1月にベータ版としてサービスをリリースしました。 ベータ版までは ほとんど1人で開発され、現在は3名で開発を行っています。 立ち上げのスピードを重視して、
🚀 10x easier, 🚀 140x lower storage cost, 🚀 high performance, 🚀 petabyte scale - Elasticsearch/Splunk/Datadog alternative for 🚀 (logs, metrics, traces). OpenObserve (O2 for short) is a cloud-native observability platform built specifically for logs, metrics, traces, analytics, RUM (Real User Monitoring - Performance, Errors, Session Replay) designed to work at petabyte scale. It is straightfor
はじめに レバテック開発部、SREチームに所属している金澤です。 弊社開発部では、Datadogで行っていた監視からNewrelicを用いたオブザーバビリティへの移行を行う決定をしました。 そして、なぜオブザーバビリティを採用したのか、DatadogからNewrelicへ移行したのかといった意思決定をADRとして記録し、社内に展開しています。 今回はこのADRの内容を公開します！ ※本記事はNewrelic、Datadogを肯定、否定するものではございません。 ADR コンテキスト 事業軸 レバテックの事業戦略は事業ポートフォリオ構想に従っている 既存の事業を拡大させながら新規サービスを生み出し続ける 事業ポートフォリオ構想 開発軸 事業領域の大きさ、深さが拡大し必要なドメイン知識が肥大化 スケーラビリティとアジリティの担保が困難になってきた バグ、障害の発生 レビュー工数の増加 新規参画
At Airplane, we collect observability data from our own systems as well as remote “agents” that are running in our customers’ infrastructure. The associated outputs, which include the standard “three pillars of observability” (logs, metrics, and traces) are essential for us to monitor our infrastructure and also help customers debug problems in theirs. Over the last year, we’ve made a concerted ef
はじめに SRE部 ECプラットフォームSREチームの小林 (@akitok_) です。 ZOZOTOWNでは、マイクロサービス間通信におけるトラフィック制御のために、Istioによるサービスメッシュを導入しています。本記事ではZOZOTOWNのマイクロサービスプラットフォーム基盤（以下、プラットフォーム基盤）において、Istioをいかにプロダクションレディな状態で本番に投入していったか、その取り組みを紹介します。 なお、Istioによるサービスメッシュを導入した背景については、以下の記事で紹介しています。 techblog.zozo.com はじめに What is Istio? Istioをプロダクションレディにするまでに直面した3つの課題 どのようにリソース消費量を見積もるか Data Planeサイジング Envoyプロキシのチューニング 負荷試験 Istioベンチマーク試験 サー
こんにちは・こんばんは・おはようございます、エンジニアのid:aerealです。 この記事では筆者が開発に参加しているサービスの監視フレームワークをOpenTelemetryへ移行した際の体験を紹介します。 OpenTelemetryとは OpenTelemetry is an Observability framework and toolkit designed to create and manage telemetry data such as traces, metrics, and logs. What is OpenTelemetry? サイトの説明にある通り分散トレースやメトリクス、ログなどの指標を扱う監視フレームワークです。 OpenTracingやOpenCensusなどを継承・統合したプロジェクトと言うと合点がいく方も多いのではないでしょうか。 OpenTelemet
GitHubの年次イベント「GitHub Universe 2023」が米サンフランシスコで開幕。1日目の基調講演で、GitHub Copilotがサードパーティの開発者向けツールやオンラインサービスなどと統合可能になることが発表されました。 例えば、Copilot Chatのチャットで、Datastax社が提供するNoSQLデータベース「Cassandra」の現在のクエリ性能に問題がないかを質問し、回答を得ることができます。 また、Cassandraの性能を改善するにはどうすればいいか、といったサードパーティ製品が備えるナレッジもCopilotに提供され、回答できるようになります。 Copilotとサードパーティ製品との統合はパートナープログラムを通して行われ、第一段としてDatastax、LaunchDarkly、Postman、Hashicorp、Datadogなどを含む25社以上が
フロントエンドのダッシュボードを作ってみたらいい感じだったので紹介です。 作ったもの zx と Datadog、GitHub Actions を使って以下画像のように、フロントエンドのコードベースの各指標を可視化するダッシュボードを作りました。 値はデモ用に書き換えています 現在、計測している指標はこちらです。 Vue SFCファイルにしめるTypeScriptの割合 Vue SFCファイルにしめるComposition APIの割合 strict: trueにした場合のType Errorの数（tsc & vue-tsc） Jestの各種カバレッジ 各指標は毎朝9時に更新していて、時系列での推移も確認できます。 なぜ作った？ 技術的負債解消等コードベースのリファクタリングの活動は、機能追加に比べ進捗を把握しにくい、成果が伝わりにくいという問題があり、それを解消したいと考えたからです。 こ
こんにちは、Platform Team というチームでマネージャーをしている荒引 (@a_bicky) です。 Platform Team は、データエンジニア・アーキテクト的な役割を担う Repro Core Unit と、インフラエンジニア・SRE 的な役割を担う Sys-Infra Unit から成るチームです。 先月 SRE Lounge #15 で「何でも屋になっている SRE 的なチームから責務を分離するまでの道のり 〜新設チームでオンコール体制を構築するまで〜」と題して次の発表をしたんですが、時間の都合上話せなかった内容があるので、それらについて触れたいと思います。 なお、当日の発表内容は動画でも視聴可能です。 アジェンダ 本エントリーのアジェンダは次のとおりです。 SRE Lounge #15 での発表内容の要約 Repro Core と Sys-Infra の棲み分け R
バクラク事業部 Platform Engineering 部の uehara です。2023年4月に入社しました！ この記事では、直近で取り組んだ Datadog のコスト最適化の取り組みを紹介します。 概要 大きく2つの施策によって、Datadog の月額料金を 30% ほど削減しました。 毎月の利用量を事前コミットすることで単価を下げた ログ運用を見直すことでコストを約半分にした 利用量の事前コミット Datadog の一部機能では利用量を事前コミットすることで単価を下げることができ、価格表も公開されています。BILLED ANNUALLY が年契約、BILLED MONTH-TO-MONTH が月契約の単価です。 www.datadoghq.com オンデマンド料金と比較すると2割から3割ほど安くなっていることが分かります。 直近の利用実績から毎月必ず利用する分を算出し、MONTH-
はじめに こんにちは。計測プラットフォーム開発本部SREブロックの纐纈です。今年の4月に入社し、ZOZOMATやZOZOGLASSの運用改善に取り組んでいます。また、今年の夏US向けにZOZOFITをリリースしましたが、そちらの機能追加にも今後関わっていく予定です。 計測システムでは最近Argo Rolloutsを導入してカナリアリリース、自動ロールバックを実現しました。本記事では、その具体的な導入方法と効果についてお伝えします。 目次 はじめに 目次 Argo Rollouts導入前のリリースの問題 カナリアリリースの導入 導入後の効果 ツールの選定 Argo Rolloutsについて DeploymentからRolloutへの移行 1. 既存のDeploymentを参照するRolloutリソースを作成して、Podを立ち上げる 2. HPAの対象をDeploymentからRolloutに
この記事では モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス - MonotaRO Tech Blog のうち、主にアーキテクチャにおける詳細について紹介します。 自己紹介 マイクロサービス化について 課題を認識する スコープと技術選定 ゴールイメージを共有する 既存コードから分かった問題点 曖昧なデータ構造 処理フローの混在 アドホックなデータ取得 効果的な改善を行う 処理フローを分割する N+1問題とロジックの独立性を考慮した設計 安全に移行する 実行時のデータを取る 新旧比較による検証 まとめ 自己紹介 藤本 洋一 プラットフォームエンジニアリング部門 CTO-Officeグループ AVLチーム 楽天、SaaSベンチャーを経て、モノタロウに入社してマイクロサービス化にとりくむエンジニアの話 2019年5月入社。商品検索基盤のマイクロサービスと
2024/09/11 New Relic User Group Vol.11 ただのLT大会『より快適なエラーログ監視を目指して』 レバテックでの Datadog から NewRelic への移行に際し、エラーログの Slack 通知を改善し、より快適なエラーログ監視を実現したお話です。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く