GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる GitHubが提供するGitHub.comは、世界最大のソースコード管理システムを始めとするソフトウェア開発者向け支援サービスを提供しています。 そのGitHub.comはRuby on Railsで構築されており、同社はつねにRubyとRuby on Railsをアップデートし続けていることを今年（2023年）4月に明らかにしています。 参考：GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている そして同社はこのGitHub.comを支える1200台以上のMySQL 5.7を、GitHub.comのサービスレベルを維持したまま1年以上かけてMySQL 8.0にアップグレードしたことをブログで明らかにしました。 Up
5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる
はじめに 本稿は、オープンソースの可観測性(Observability)プロジェクトである OpenTelemetry を取り上げた書籍「Learning Opentelemetry」の読書感想文です。従来の可観測性の課題であったデータの分断を解消し、トレース、メトリクス、ログなどの様々なテレメトリデータを統合的に扱うことができる OpenTelemetry は、可観測性の分野における革命的な存在と言えます。 過去10年間で、可観測性はニッチな分野から、クラウドネイティブの世界のあらゆる部分に影響を与える数十億ドル規模の産業へと発展しました。しかし、効果的な可観測性の鍵は、高品質のテレメトリデータにあります。OpenTelemetryは、このデータを提供し、次世代の可観測性ツールと実践を開始することを目的としたプロジェクトです。 learning.oreilly.com 本書の想定読者は、
PHPカンファレンス関西2024での発表資料です https://fortee.jp/phpcon-kansai2024/proposal/42712995-5f3e-4c68-a951-39584eac95a1
オブザーバビリティ研修実践編
株式会社サイバーエージェント AI事業本部 2024年度エンジニア新卒研修 オブザーバビリティ研修実践編（一部社内向けの内容）
はじめに こんにちは。WEARバックエンド部SREブロックの春日です。普段はWEARというサービスのSREとして開発・運用に携わっています。本記事では、約60％のコスト削減に成功したNATゲートウェイの通信内容の調査方法と通信量の削減方法についてご紹介します。 目次 はじめに 目次 背景 コストの把握 NATゲートウェイの通信内容の把握 CloudWatchメトリクスでの確認 VPCフローログでの確認 リゾルバーでのクエリログでの確認 調査結果をもとにNATゲートウェイ経由での通信量を削減する AWSサービスとの通信 Datadogとの通信 WEARのAPIとの通信 ECRパブリックリポジトリとの通信 結果 まとめ 背景 ZOZOではより効果的な成長を目指してコストの最適化を進めています。コストの増大はサービスの拡大を鈍化させる原因となるため、常に最適な状態に保つことが必要です。WEARで
はじめに 有用な知識の特性 Google SRE リソース Site Reliability Engineering: How Google Runs Production Systems The Site Reliability Workbook: Practical Ways to Implement SRE Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems SLO Adoption and Usage in SRE Creating a Production Launch Plan Training Site Reliability Engineers: What Your Organization Needs to Cre
“LLM for SRE“の世界探索 - ゆううきブログ
ChatGPTが登場した当初、対話や要約、翻訳、コード生成などの典型的な言語タスクができても、SREやAIOpsの研究開発にはあまり関係ないのではないかと正直思っていた。AIOpsでは典型的にはいわゆるObservabilityデータ（メトリクス、ログ、トレースなど）が入力となるため、自然言語ではなく数値のデータを解析することが求められる。自然言語のタスクを研究対象としていなかったため、AIOpsとChatGPTに強い関係性は見いだせなかった*1。 しかし、自分で大規模言語モデル（Large Language Model: LLM）を日常的に使用したり、表題にあるようにSREのためのLLM（LLM for SRE, LLM4SRE）に関する論文を読むうちに、LLMのテキスト生成器としての性質よりもその優れた推論機械としての性質に注目するようになった。特にSREの障害診断は、人間の専門家が推
イベント名: オブザーバビリティ再入門 - 大切さと高め方を知ろう！ イベントURL: https://mackerelio.connpass.com/event/316449/ 概要: 可観測性の概念を理解し、OpenTelemetryなどの実装に必要な道具があっても、自分たちのプロダクトやチーム…
スタディサプリ最大のRailsアプリケーションにYJIT+pitchforkを導入してメモリ使用量を劇的に削減するまで - スタディサプリ Product Team Blog
こんにちは。SREのkyontanです。Rubyが大好きなのでRubyの話をします。ちなみにリクルートはRubyKaigi 2024へGold Sponsorとして協賛しています! *1。ぜひ沖縄でお会いしましょう。 これはあるアプリケーションのメモリ消費量を示すグラフなのですが、まさかgemを入れ替えるだけでこんなに嬉しい変化が見られるとは思っていませんでした。今日はそんなgemの話をします。 話は遡って2023年4月のある日、インターネットを眺めていたところ、ShopifyがpitchforkというOSSを公開したという情報が目に留まりました。 調べてみると、どうやら著名なRackサーバー実装の1つであるunicornの派生版であり、メモリ使用量の削減に特化しているらしいのです。 github.com これはスタディサプリ小中高のあのリソースドカ食いマイクロサービス第一位である api
Home Home Guides Data types Tools Curated recipes FAQ Contributors オブザーバビリティとは¶ 概要¶ オブザーバビリティとは、観測対象のシステムからのシグナルに基づいて、継続的にアクション可能な洞察を生成および発見する機能です。つまり、オブザーバビリティを使用すると、システムの状態を外部出力から理解し、(修正)アクションを実行できます。 対処する問題¶ コンピュータシステムは、CPU 時間、メモリ、ディスク領域などの低レベルのシグナルや、API 応答時間、エラー、トランザクション毎秒などの高レベルかつビジネス上のシグナルを観測することで測定されます。 システムの可観測性は、その運用と開発コストに大きな影響を与えます。観測可能なシステムは、操作者に意味のある実行可能なデータを提供し、(インシデント応答の高速化、開発者生産性の向
Observability を実現するためにアセットを活用しよう（AWS 秋の Observability 祭り ~明日使えるアセット祭り~ ）
【批判ではない】最近の技術用語をなんでもカタカナ化するのをやめたい【答えでもない】 - inductor's blog
オブザーバビリティについて説明すると「それモニタリングですよね」みたいなツッコミをされる穴があるので、なんらかの excuseをしたいのだが、本心では オブザーバビリティとモニタリングってそもそも類似点や相違点を語ること自体がおかしくないかと思っているよ。— 統合開発環境 (@sadnessOjisan) 2024年8月27日 これを見て オブザーバビリティってかっこよくカタカナで言わずに、可観測性の確保って言い続ければいいんだよ。— inductor / Kohei Ota (@_inductor_) 2024年8月28日 包含関係はある（つまり、可観測性の必須要素に監視はある）が、監視の主体とする目的が必ずしもすべて可観測性の実現によって解決されるとは限らなくて、目的が違う— inductor / Kohei Ota (@_inductor_) 2024年8月28日 って日本語で説明し
オブザーバビリティには限りがない話
先日NewRelicの清水さんにマンツーマンでオブザーバビリティの話をきかせてもらえるという貴重な経験をした。長年アプリケーションレイヤーも含んでシステム運用の経験があると「あるある」な話なのだが、次のようなことが起こる。 何か不具合や障害が起こる 該当時刻のエラーログなどを見るが情報が少なく、原因を特定する決定打に欠ける 次回、また同じことが起こったときには原因を特定できるように、printfデバッグするコードを大量に埋め込んだバージョンに更新して、デプロイする もう一度起こるのを待つ これは最初の状態が「オブザーバビリティに欠けた状態」だったと言える。めちゃ納得してEnter Sandmanくらいヘドバンして頷いてしまう。 僕の経験上このようなケースを避けるために良い結果を出してきたのは、Javaの例外が出た箇所でスタックトレースを取得しておくことだ（僕らは単にログファイルに吐いておい
Secrets from the Algorithm: Google Search’s Internal Engineering Documentation Has Leaked
Watch Our Google Algorithm Leak Webinar Replay Google, if you’re reading this, it’s too late. Ok. Cracks knuckles. Let’s get right to the Google algorithm leak. Internal documentation for Google Search’s Content Warehouse API has been discovered. Google’s internal microservices appear to mirror what Google Cloud Platform offers and the internal version of documentation for the deprecated Document
TypeScript の型システムを活用して、本番のアプリケーションにおける実用的な問題を解決することを目指しています。Effect-TS は、以下のような特徴を備えています。 並行性（concurrency）：Fiber ベースの並行モデルにより、高いスケーラビリティと低レイテンシを実現 コンポーザビリティ（composability）：小さく再利用可能なパーツを組み合わせることで、メンテナンス性、可読性、柔軟性の高いソフトウェアを構築する リソースの安全な管理（resource-safety）：処理が失敗したとしても、安全にリソースを開放する 型安全性（type-safety）：TypeScript の型システムを活用した型推論と型安全性に焦点を当てている エラー処理（error handling）：構造化された信頼性の高い方法でエラーを処理する 非同期性（asynchronicity
デジタル時代の企業にとって、システムの安定稼働と迅速な問題解決は、競争力を維持するための重要な要素です。21社にご寄稿頂いた「Amazon CloudWatch」「Datadog」「Grafana」「New Relic」「Prometheus」「Sentry」「Splunk」の各ツールレビュー記事を参照・抜粋し、それぞれの企業がどのようにシステムの健全性を確保し、未来の課題に備えているのかをアーキテクチャを通してご紹介します。 ※ツール名・ご寄稿企業名共にアルファベット順で掲載しております Amazon CloudWatchAWS CloudWatchは、AWSのクラウドリソースとアプリケーションの監視と管理を行うためのサービスです。メトリックス、ログ、イベントなどを収集、追跡し、可視化することで、システム全体の状態を把握し、問題の早期発見と解決をサポートします。 ▼Amazon Clou
はじめに こんにちは、IT 戦略部システム基盤グループの井戸です。 当グループは社内向けに様々なサービス（GitHub、Jira、Confluence など）を提供し、それらの運用を担当しています。最近では社内向けサービスに SaaS を活用する機会が増え、その数も増加しています。 SaaS を利用することは、従来のオンプレミスのサービスと比較していくつかのメリットがあると言われており、概ねその通りだと思います。 物理サーバーを購入する必要がないため、導入コストが低い 月額利用が一般的なため、利用開始や解約のハードルが低い ベンダーがセキュリティ対策を担当するため、ユーザーはセキュリティを意識する必要がない クラウド上でサーバーの管理が行われるため、物理的なスペースを確保する必要がない 障害時の対応はベンダーが行うため、自ら対応する必要がない ただし、「障害時の対応はベンダーが行うため、自
フロントエンド監視の全体像と実現方法
必要性 フロントエンドの監視はバックエンドやインフラのそれらと比べ、優先度が低くなりがちです。 バックエンドやインフラでの障害はサービス継続に直結するため、これは当然と言えば当然なのですが、別の理由もあると考えています。 それは計算リソースをサービス提供側が管理していないことです。 例えばアプリケーションがインフラとして AWS を利用しているなら、AWS のリソースを管理するのはサービス提供側です。 これは AWS 以外のクラウドサービスプロバイダやオンプレであっても同様です。 一方でフロントエンドはエンドユーザのブラウザ上で動作し、これを管理しているのはエンドユーザです。 フロントエンドはその性質上、監視の「盲点」になりがちです。 しかしフロントエンドはエンドユーザが直接触れるものであるため、そこで何が起きているかサービス提供側は正確に把握する必要があります。 マイルストーン フロント
AWS オブザーバビリティの向上 – Amazon CloudWatch アラームの力を引き出そう | Amazon Web Services
Amazon Web Services ブログ AWS オブザーバビリティの向上 – Amazon CloudWatch アラームの力を引き出そう 通常、組織はAWS サービスを活用してワークロードのオブザーバビリティと運用の優秀性を高めています。しかし、多くの場合、オブザーバビリティメトリクスが提供されたときのチームが取るべき対応は不明確であり、どのメトリクスに対処が必要で、どのメトリクスがノイズにすぎないかを理解することは難しい場合があります。たとえば、アラームがトリガーされるまで 10 分以上かかる場合、根本的な問題を軽減するためにチームが取れる対処が遅れてしまいます。この問題への理想的な解決策は、ネットワークの障害を防ぐために、オブザーバビリティメトリクスからアラームの起動までの時間を短縮することです。実装やアーキテクチャの制限により、メトリクスデータは常に CloudWatch
社内の基盤を活かして爆速開発を実現するために重視したマイクロサービステンプレートの5つの要点 - MonotaRO Tech Blog
はじめに 転職後の二つの喪失感への対応 所属チームの現状とMonotaROのアプリケーション/サービス共通基盤（所謂プラットフォーム） 所属チームの状況 社内プラットフォームの状況 マイクロサービス開発のためのテンプレートの導入 開発のロケットスタート：テンプレートの早期提供 テンプレート作成の5つの要点 1. ベンダー非依存なObservabilityの実装 2. CI/CDを早期に提供（特にLinterを最初期に） 3. APIプロトコルとして、JSON over HTTPとgRPCの双方をサポート 4. 最低限の薄いフレームワーク 5. セントラルProtobufリポジトリの提供 現在の取り組み (2023年10月以降)と今後の展開 さいごに はじめに はじめまして、MonotaROのCTO-Officeに所属する伊藤と申します。 github.com recruit.monotar
公開日 2024/06/26更新日 2024/07/25モダンな開発環境のBtoB SaaSアーキテクチャ特集 技術選定のポイントと今後の展望 ご好評頂いているアーキテクチャ特集の第三弾となる今回は、BtoB SaaSを提供する企業10社にご協力頂き、技術選定のこだわりや今後の展望をご寄稿いただきました。アーキテクチャを通して、各社の事業特性や設計思想にも触れられる内容となっております。※ご紹介は企業名のアルファベット順となっております 株式会社あしたのチーム あしたのチームは「誰もが "ワクワク" 働ける世界を創る」をビジョンに掲げ、人事評価制度の構築・運用・クラウド化で "人と組織の成長" を支援しています。今回は、2024年4月にリリースされた同社の新サービス：パフォーマンスマネジメントプラットフォーム『Cateras™』のアーキテクチャについてご説明します。 アーキテクチャ選択の背
初めに 本記事 『ゼロから始めるシステム障害対応フロー』 の内容について タイトルの「ゼロから始める」には二つの意味があります。プロダクトのリリースを間近に迎える中、チーム内での障害対応体制の枠組みがなかったこと。そして体制づくりを担当することとなった私の知識・知見が（ほぼ）ゼロだったこと。この二つです。 この状態から、リリース前〜リリース後の約2月間でなんとか形にすることができました。本記事ではその過程でぶつかった問題とそれに対する課題、それらにどう対応したのか、何を学んだのか、の紹介。 そして、障害対応体制の策定・構築や改善の流れの中で私が起こした失敗から、人としてリーダーとして何を心がけなければいけなかったのかの反省を共有させてもらいたいと思います。 本記事は以下の構成です。 0. 始まり ※ スクラムチームでの話。スクラムチームの登場人物は以下の三つ PO：プロダクトオーナー（Pd
日本の医療システムの再構築を目指すスタートアップ「カケハシ」のフロントエンド領域でのチャレンジ / Challenges in the frontend domain at “Kakehashi”
sumirenです。 技術顧問やSREをしています。 背景 2024年現在、OpenTelemetryが盛り上がっており、ベンダへの依存度を下げてテレメトリを収集・送信することがトレンドになってきているように思います。多くの企業様で、OpenTelemetry対応のオブザーバビリティバックエンドを選定されているのではないでしょうか。 一方で、E2E自動テストツールなどもそうですが、デベロッパーツールは画面やUXの情報がパブリックな情報として出回ることが少ないように思います。オブザーバビリティバックエンドの場合、シグナル3種に関してOpenTelemetryベースでもフルに機能が活用できるのかという疑問もあります。 そうしたこともあり、オブザーバビリティバックエンドは実際にトライアルしてみないと選定しづらいです。監視など狭義のオブザーバビリティ外の機能や、OpenTelemetryの範囲外の
公開日 2024/05/30更新日 2024/07/25オブザーバビリティの最前線 OpenTelemetryで下げる認知負荷~活用事例4選~ 近年マイクロサービスアーキテクチャの普及やクラウドネイティブの普及が進み、システムの複雑性は増す一方です。システムの動作を正確に把握することはますます困難になっており、そのような状況の中で、オブザーバビリティはシステムを安定的に運用するために必要不可欠な要素になってきています。 そして、オブザーバビリティの重要性の認知が高まるにつれて、多くの企業でオブザーバビリティに関するツールの導入も進み始めています。 そのような潮流の中、オブザーバビリティ分野でさらなる大きな可能性を持つプロジェクトがOpenTelemetryになります。 本記事では、OpenTelemetryとは一体どんなものなのか、そして実際にOpenTelemetryの導入・活用に成功し
メンテナンスコスト削減を実現したOpenTelemetryへの挑戦 ～NTTデータに学ぶ、オブザーバビリティの取り組み～ - Findy Tools
公開日 2024/08/14更新日 2024/08/09メンテナンスコスト削減を実現したOpenTelemetryへの挑戦 ～NTTデータに学ぶ、オブザーバビリティの取り組み～ オブザーバビリティの重要性が高まっている現在、その実現に向けたオープンソースプロジェクトであるOpenTelemetryが注目を集めています。一方、OpenTelemetryの具体的な導入事例やOpenTelemetryを用いたオブザーバビリティの取り組みについては、発信されている情報はまだ多くありません。 そんななか、Findy Toolsでは株式会社NTTデータの取り組みに注目。NTTデータでは、クラウドネイティブ環境やマイクロサービスアーキテクチャの採用増加に伴い、システムが複雑に。この課題に対応するため、OpenTelemetry を軸としたオブザーバビリティの実現に積極的に取り組んでいるといいます。 今回
こんにちは！ シェルフィー株式会社で SRE を担当している石田です。 弊社では、本番のワークロードにて Fluent Bit を使っております。 今回、Fluent Bitの処理について理解を深めたので記事を書いてみました。 世界中で使われているとても有名なミドルウェアなので、参考になればとても嬉しいです。 はじめに 弊社では、ECS on Fargate で稼働しているバッチジョブのログをサイドカーコンテナ（Fluent Bit）を使い Datadog に連携しています。 ログのサイズが 16 KB 以上ある場合、shim-logger の仕様により、そのログは分割されてしまうため、 Fluent Bitにて分割されたログの再結合処理を行う必要性があります。 この点についてはDeNAさんの記事がわかりやすいので、詳細はそちらを参考にしてもらえたらと思います。 AWS ECS on Fa
OpenTelemetry を利用して PHP アプリケーションのテレメトリデータを計装する方法をまとめました。 本エントリのコードは下記で公開しています。 github.com OpenTelemetry とは 用語 PHP アプリケーションのマニュアル計装（手動計装） 構成 OTel Collector Jaeger 動作環境 必要なパッケージ PHP コード 設定 実行 PHP アプリケーションのゼロコード計装（自動計装） 必要な拡張とパッケージ 設定 PHP コード 実行 さいごに 参照 OpenTelemetry とは opentelemetry.io OpenTelemetry は、サービスやアプリケーションのテレメトリーデータ（トレース、メトリクス、ログなど）を計装、生成、収集、送信するためのオブザーバビリティフレームワークです。ベンダーニュートラルな OSS であり、CNC
はじめに エンジニアとして就職する前に読んだ「なれる!SE 2週間でわかる?SE入門」の内容があまりにも厳しく、業界に就職するのが怖くなったことを覚えています。本の中に登場する中学生の少女にしか見えない凄腕のSE、室見立華さんのような人物は現実には存在しないでしょうが、実際の業界には彼女のような凄腕エンジニアや年齢不相応な技術力を持つ人間も確かに存在します。 なれる！SE ２週間でわかる？ＳＥ入門 (電撃文庫) 作者:夏海 公司,IxyKADOKAWAAmazon SREの探求『Becoming SRE』の内容紹介 私は「なれる!SE」が好きすぎるあまり、「なれる!SRE」というタイトルのクソみたいな文章を吐き出したこともありましたが、そのクオリティがあまりにも低かったため、外には公開せずに留めておきました。そんな中、SREの探求の原著者であるDavid Blank-Edelman(ott
Grafana Integrationsを使って10分でMacOSのダッシュボードを作成し、Grafanaの基礎を学ぶ | DevelopersIO
Grafana Integrationsを使って10分でMacOSのダッシュボードを作成し、Grafanaの基礎を学ぶ Grafanaの学習目的で利用するデータソースは永遠の課題ですが、今回はクライアントPCのメトリクスを利用して、PrometheusやLokiを学ぶ方法を紹介します。 「Grafanaのダッシュボードあれこれ触ってみたいけれど、実際やるなら自分の身近にある機器のメトリクスを使ってやってみたいよなぁ」 Grafanaには、学習目的でTestData data sourceが公式から提供されています。ダッシュボードの表示形式を手を動かしながら学ぶには良いデータソースなのですが、いかんせんテスト用のデータなので、実際のユースケースからは遠かったり、クエリがシナリオとして隠蔽されているため、Grafanaの基本であるPrometheusやLokiを学ぶには不向きです。 どうしたも
モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス - MonotaRO Tech Blog
こんにちは。モノタロウのTechBlog編集チームです。 モノタロウではECサイトでのお客様体験の向上を目指して、日々改善に取り組んでいます。 商品の出荷目安などの出荷関連情報は重要な要素の1つになります。 今回は、出荷関連情報の正確性を改善するとともにシステムの変更容易性を向上させるためにマイクロサービス化に取り組んだ活動をインタビューしました。 自己紹介 納期表示を高度化する サプライヤ在庫連携機能開発のつらみ AVLのマイクロサービス開発のすすめ方 リリース・監視・その後の展開 おわりに 今回インタビューしたみなさん 自己紹介 山崎 章裕 ECシステムエンジニアリング部門 開発生産性グループ、プラットフォームエンジニアリング部門 CTO-Officeグループ AVLチーム兼務 2019年8月に入社し、主にECサイトの注文・配送周りのプロジェクトにテックリードとして関わる。またECサイ
Platform Engineering on Kubernetes を読んでCloud Native の現在地を理解する - じゃあ、おうちで学べる
はじめに 近年、Kubernetesの採用が進む中、複数のチームが関わり、複数のクラウドプロバイダーへのデプロイを行い、異なるスタックを扱う組織では、その導入の複雑さが新たな問題となっています。本書 『Platform Engineering on Kubernetes』は、Kubernetes に登場しつつあるベストプラクティスとオープンソースツールを活用し、これらのクラウドネイティブの問題を技術的に組織的にどのように解決するかを示してくれます。 learning.oreilly.com 本書では、Kubernetes上に優れたプラットフォームを構築するための要素を明確に定義し、組織の要件に合わせて必要なツールを体系的に紹介しており、実際の例とコードを交えながら各ステップをわかりやすく説明することで、最終的にはクラウドネイティブなソフトウェアを効率的に提供するための完全なプラットフォーム
はじめに 本書『Observability Engineering』は、複雑化の一途をたどる現代のソフトウェアシステムに立ち向かうための、強力な武器となる一冊であり本稿はその読書感想文です。Observability Engineering を今から知りたい方はもちろん、Observability Engineering の基礎を改めて学びたい方もぜひお読みください。この記事もかなりの長さになるので普通に書籍を読んだほうがいいかもです learning.oreilly.com 「Observability:可観測性」という言葉は、近年ソフトウェアエンジニアリングの世界で大きな注目を集めています。しかし、その概念の本質を理解し、実践に移すことは容易ではありません。 本書は、そのオブザーバビリティについて、その基本的な考え方から、具体的な実装方法、そして組織への適用まで、幅広くかつ深く解説して
Mackerel 10周年！開発とエンジニアの”ワクワク”を支え続けた歴代PdMからのメッセージをリリース変遷を添えてお届けします #mackerel10th - Mackerel ブログ #mackerelio
いつもMackerelをご利用くださりありがとうございます。 おかげさまで、Mackerelは2024年9月17日で10周年を迎えました。 日本製サーバー監視サービス Mackerel の誕生は遡ること11年前の2013年、はてな社内で行われた事業プランコンテストがきっかけでした。*1 2014年9月17日の正式リリースからたくさんの方々にご利用いただいてきたMackerelそして監視・運用の技術を取り巻く潮流は変化し続けており、Mackerelもいま、これまでの「サーバー監視・管理」の領域から「オブザーバビリティ」領域の開発へと、さらなる進化の転換期になっています。 今回は、激しく変わっていく世の中でもMackerel が変わらず大切にしている「エンジニアを”ワクワク”させること」を支え、Mackerel のプロダクト開発をリードしてきた歴代のプロダクトマネージャーから、10周年を迎えた
はじめに チームトポロジーとは プラットフォーム開発組織に存在した課題 SRE何でも屋問題 中長期課題に取り組めない問題 チームトポロジーを元にした組織見直し SRE Deskを3つのDeskに分割 SRE DeskとPlatform Engineering Deskの違いを明文化 見直しの効果 見直しを通じての所感 最後に はじめに こんにちは。enechainでCTOを務めている@sutochin26です。 enechainでは、組織拡大に伴いSRE/Platform関連業務を行うチームの体制見直しを行ないました。 その際に、チームトポロジーの考え方を参考にする事で方針の言語化がしやすくなり、認識合わせの助けになりました。 SREとPlatform Engineeringをチームトポロジー視点で定義すること自体は新しくはないですが、本記事では実際に現場で生じていた課題と共にお話します。
Next.js 15
Next.js 15 is officially stable and ready for production. This release builds on the updates from both RC1 and RC2. We've focused heavily on stability while adding some exciting updates we think you'll love. Try Next.js 15 today: # Use the new automated upgrade CLI npx @next/codemod@canary upgrade latest # ...or upgrade manually npm install next@latest react@rc react-dom@rc We're also excited to s
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
オブザーバビリティ導入の教科書〜「投資対効果は？」に負けないオブザーバビリティの導入方法〜 - Findy Tools
公開日 2024/11/12更新日 2024/11/14オブザーバビリティ導入の教科書〜「投資対効果は？」に負けないオブザーバビリティの導入方法〜 システムから出力されるあらゆる情報を計測し、システム内部の状態が常に観測・制御可能な状態を指す「オブザーバビリティ」。開発生産性の向上のほか、顧客満足度の向上や事業成長への貢献にもつながるとあって、近年注目を集めています。しかし、その重要性は理解していても、社内での導入や浸透となると難しいもの。特に、現状の監視体制で十分だと考える経営陣を説得し、新たなツール導入や体制構築に向けて動き出すのは簡単なことではありません。 そこでFindy Toolsでは、オブザーバビリティプラットフォームを提供するNew Relicの上席エヴァンジェリストの清水氏へインタビューを実施。オブザーバビリティの価値、New Relicの独自の強み、そして導入による事業貢
ISUCONの過去問でObservabilityを体験する - Hatena Developer Blog
システムプラットフォームチームで SRE をしている id:masayoshi です。 今年もISUCON14の開催が決定しましたね！ isucon.net ISUCONとはLINEヤフー株式会社が運営窓口となって開催している、お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトルです ISUCONは、世の中に実際にありそうなWebサービスを題材に、明確なボトルネックがあるコードかつ全体のコード量もすぐ読める量なので、パフォーマンスチューニングの練習にはもってこいです。 適切なパフォーマンスチューニングをするためには、まず計測してシステム上のどこにボトルネックが存在してパフォーマンスが悪化しているのかを把握する必要があります。 このように、どこで、何が起こり、パフォーマンス上の問題やエラーがおこっているのかを把握できる能力を Observabili
OSSでオブザーバビリティを実現する (Grafana Stack x OpenTelemetry on Kubernetes) - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに こんにちは。SREの gumamon です！ NewRelic、Datadog、モダンな監視ツール(オブザーバビリティ)って良いですよね。弊社もKubernetes(k8s)等を利用した環境が増えてきた折、そろそろ必要になってきたのですが、NewRelic、Datadog等のクラウドサービスはランニングコストが高くなりがちです。 では内製できないかやってみよう！・・・というようなことを昨年度から取り組んでいたのですが、やっとこさ形になりましたので改めてブログで紹介させて頂こうと思います。 今回ご紹介するのは、大まかなシステムの構成と設計時の観点です。各コンポーネントの詳細や工夫できた点などについては、改めて別の記事でご紹介できればと思います。 また、「オブザーバビリティとは？」や「試行錯誤の過程」については、以前執筆した以下のブログをご参照ください。 tech-blog.raku
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる
アプリケーションエンジニアこそ「監視」だよね！と私が考える訳 #phpkansai
NATゲートウェイの通信内容を調査して対策し、コストを約60％削減した話 - ZOZO TECH BLOG
このSRE本がすごい！2024年版 - じゃあ、おうちで学べる
メトリクス、ログ、トレースをうまく使い分けて可観測性を高めよう！
AWS Observability Best Practices
Amazon_CloudWatch_ログ異常検出_導入ガイド
エラーや非同期処理をより安全に扱うための TypeScript ライブラリ Effect-TS
21社の監視・オブザーバビリティ アーキテクチャ特集 - Findy Tools
DeNA 流 SaaS の外形監視手法 | BLOG - DeNA Engineering
モダンな開発環境のBtoB SaaSアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
ゼロから始めるシステム障害対応フロー - Qiita
クリティカルユーザージャーニーを利用した SLI/SLO の改善 / #mackerelio
【OpenTelemetry】オブザーバビリティバックエンド8種食べ比べ
オブザーバビリティの最前線 OpenTelemetryで下げる認知負荷~活用事例4選~ - Findy Tools
Fluent Bit の低レイヤーに飛び込んでみて、わかったこと
PHP アプリケーションのトレース計装ではじめる OpenTelemetry 入門 - Shin x Blog
なれる!SRE - Becoming SREで学んだこと - じゃあ、おうちで学べる
もう一度読むObservability Engineering - じゃあ、おうちで学べる
チームトポロジーの観点で見直すプラットフォーム開発組織 - enechain Tech Blog
Migrating to OpenTelemetry | Airplane