全AWSエンジニアに捧ぐ、CloudWatch 設計・運用 虎の巻 / CloudWatch design and operation bible全AWSエンジニアに捧ぐ、CloudWatch 設計・運用 虎の巻 / CloudWatch design and operation bible
Logging in Python like a PRO 🐍🌴
Beyond exception handling, there's something else I see people struggling with, which is logging. Most people don't know what to log, so they decide to log anything thinking it might be better than nothing, and end up creating just noise. Noise is a piece of information that doesn't help you or your team understand what's going on or resolving a problem. Furthermore, I feel people are uncertain ab
データ分析基盤におけるオブザーバビリティの取り組み
GMOペパボ株式会社では主にGoogle Cloud Platformのサービスを利用してデータ分析基盤を構築し運用しています。その中心となるのがデータウェアハウスのBigQueryとワークフローエンジンのCloud Composerです。また、社内向けのデータ可視化(ダッシュボード)システムではCloud Runを利用しています。 データ分析基盤から得られる情報を重要な意思決定に用いるためには、ユーザーに提供しているインフラと同様に、可用性を明らかにし、継続的に可用性を高める Realiability エンジニアリングが必要となります。本講演ではGCPで構築されているデータ分析基盤を題材として、データ分析基盤に求められる可用性や、小規模なチームにおけるオブザーバビリティへの取り組みについてご紹介します。
たった2ヶ月半でSLOを導入して事業判断に影響を与えた話 - Adwaysエンジニアブログ
こんにちは、広告サービスを担当している飛田です。 今回は "SLO導入で悩んでいる方" に向けて、弊社リワード広告サービスでのSLO策定の取り組みについてお話したいと思います。 そもそもSLOを策定するに至った経緯は二つあります。 ユーザへの影響度合いが分かりづらいパフォーマンス問題などの対応が後回しにされがちで、品質改善がなかなか進まない アラート通知があってもユーザに影響があるか即座に判断できず、静観や一部アラートを無視する状況もあり、モニタリングが形骸化しつつある 両方とも共通してユーザに与える影響を正しく把握できていないことが課題のようです。 そこでSLOを策定する過程でオブザーバビリティを高め、モニタリングの最適化とエラーバジェット運用で開発リソース配分の状況改善を図りました。 一挙両得作戦です。 細かな取り組みは順を追って紹介します。 プロジェクト初期 ワークメトリクスからSL
Grafana Lokiで構築する大規模ログモニタリング基盤 / Grafana Loki Deep Dive
CloudNative Days Tokyo 2021での登壇資料です https://event.cloudnativedays.jp/cndt2021/talks/1252
障害発生！全員集合？ － オンコールアンチパターンからの一歩前進 - Cybozu Inside Out | サイボウズエンジニアのブログ
8月だというのに涼しい日が続きますね。 kintone.comのDevOpsをしている@ueokandeです。 もうすぐAWS版kintoneのローンチからから2年が経過しようとしています。 この2年間、DevOpsチームではkintone.comのサービス安定化やスケーラビリティに注力してきました。 時には本番環境の障害で休日や深夜に障害対応することもあります。 kintone.comの障害の一次対応は、我々DevOpsメンバーが実施しています。 サービスローンチ直後は、メンバーの多くがオンコールに不慣れで、慌てて障害対応したりうまく進められないことが何度もありました。 そこでメンバー全員が効率的・効果的な障害対応を目指すべく、チームでPagerDuty社のIncident Response（非公式日本語訳版）を読むことにしました。 この記事ではAWS版kintoneで実際に体験した障害
「運用組織」の考え方と設計 〜 運用組織論 2021 / 20210310-ssmjp-operation-organization
ssmjp ssmonline #8 "第三回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/206074/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
異常検知入門と手法まとめ - Qiita
異常検知について勉強したのでまとめておきます。 参考文献 下記文献を大いに参考にさせていただきました： [1] Ruff, Lukas, et al. "A Unifying Review of Deep and Shallow Anomaly Detection." arXiv preprint arXiv:2009.11732 (2020). [2] 井手. "入門 機械学習による異常検知―Rによる実践ガイド" コロナ社(2015) [3] 井手,杉山. "異常検知と変化検知 (機械学習プロフェッショナルシリーズ)" 講談社サイエンティフィク(2015) [4] 比戸. "異常検知入門" Jubatus Casual Talks #2(2013) [5] Pang, Guansong, et al. "Deep learning for anomaly detection: A rev
RDSで接続数とメモリ消費量の調整事例 | 外道父の匠
RDS Auroraを使っているところで、OSの空きメモリが少なくなったアラートが出たので、それについて細かく考察したら、それなりの量になったのでまとめた感じです。 別にAuroraじゃなくRDS MySQLでも、MySQL Serverでも同じ話なのですが、クラウドならではの側面もあるなということでタイトルはRDSにしております。 RDSのメトリクス監視 RDSはブラックボックスとはいえ、必要なメトリクスはだいたい揃っているので、CloudWatch を見たり……APIで取得してどっかに送りつけたりして利用します。 なので、まずは接続数とメモリについて復習です。 SHOW STATUS 的には Threads_connected です。 CloudWatch Metrics 的には、DBInstanceIdentifier → DatabaseConnections です。 見た感じ、ど
Amazon SQS を使ったアプリケーションを本番で運用する際に考慮すべき基本的な 5 つのこと
Amazon SQS は可用性やスケーラビリティの高いメッセジキューサービスであり、AWS の代表的なサービスの 1 つと言えるでしょう。ところが、本番の運用に耐えられるアプリケーションにしようと思うと考えることが意外に多いものです。本エントリーでは簡単なサンプルアプリケーションをベースに、本番で運用するために考慮すべき点・注意点について見ていきます。題材として扱うのが SQS なだけで、SQS 以外を使ったアプリケーションにも応用できる内容もあるでしょう。 なお、SQS には Standard queue と FIFO queue がありますが、Standard queue を使う前提とします。 アジェンダは次のとおりです。 サンプルアプリケーション 1. ログ 2. At-least-once delivery と visibility timeout 3. デプロイ 4. 異常系 5
機械学習システムの信頼性を数値化し、技術的負債を解消する論文「 The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction」
機械学習システムの信頼性を数値化し、技術的負債を解消する論文「 The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction」 2020-04-25 [抄訳] What’s your ML test score? A rubric for ML production systemsで紹介した論文の続編があったので読んでみました。 注意)この翻訳記事は原著論文の著者陣からレビューはされていませんShunya Ueta, are providing a translation and abridgment, which has not been reviewed by the authors.Change log2021/02/03ML Test Score を簡単に計算できるGoogl
LINEのメッセージングサーバが新年のトラフィックに対応する過程
はじめに LINEの通信トラフィックは、メッセンジャーアプリ特有のパターンを持っています。新年の0時を迎えた瞬間に、ユーザ同士がLINEで新年のあいさつを交わしていることが想定され、それにより平常時に比べてメッセージの送信件数が大幅に増加します。その際、サービスを提供する国ごとに、時差や文化の違いによってさまざまなトラフィックの増加パターンを見せます。LINEでは、このような一時的なトラフィック増加を問題なく処理するため、毎年さまざまな対策を行っています。これを「新年対応」と呼んでいます。本記事では、2020年の新年対応における私たちの取り組みと、成果についてご紹介します。 LINEのメッセージングサーバが新年のトラフィックに備えるプロセス 各国で新年の0時になると、多くのユーザがLINEで新年のあいさつメッセージを送っていると想定されます。そのため、平常時より一時的にトラフィックが大幅に
BPF Performance Toolsを読んだ感想 - go_vargoのブログ
BPF Performance Toolsを読んだので、感想ブログです。 先に感想を言っておくと「最高」でした。 BPF Performance Toolsとは？ NetflixでKernel・パフォーマンスにかかわるチューニング・アーキテクチャを専門にしているBrendan Greggさんが書いた本です。BPFのiovisorというTracing分野の第一人者でもあります。 www.brendangregg.com 2019年12月に発売したばかりなので、BPFの分野では最新の本でしょう。他の著書に有名な本として(日本語版の)「詳解システム・パフォーマンス」があります。 BPF Performance Toolsは「詳解システム・パフォーマンス」第二弾と言えるかもしれません。ちなみにページ数は880Pあり、Kindleで表示される読み終わるための平均的な時間は「27時間30分」で、大作R
[CNDK2019]Production Ready Kubernetesに必要な15のこと / Production Ready Kubernetes 15 Rules
[CNDK2019]Production Ready Kubernetesに必要な15のこと / Production Ready Kubernetes 15 Rules
![[CNDK2019]Production Ready Kubernetesに必要な15のこと / Production Ready Kubernetes 15 Rules](https://cdn-ak-scissors.b.st-hatena.com/image/square/a86024b552674b0bd8fcbfe3dd22d43a58b0e2d4/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F427afd1dcd624e4080e6358129c1b754%2Fslide_0.jpg%3F14872086)
ロギングベストプラクティス - kawasima
#翻訳 https://www.scalyr.com/blog/the-10-commandments-of-logging/ CC BY 4.0 @Brice Figureau 1.自分でログの書き出しをしない printfをつかったり、ログエントリを自分でファイルに書き出したり、ログローテションを自分でやったりしてはいけない。運用担当者にお願いして、標準ライブラリやシステムAPIコールを使うようにしよう。そうすれば、実行中のアプリケーションが他のシステムコンポーネントと適切に連携して、特別なシステム設定なしに適切な場所またはネットワークサービスにログを記録できるようになる。 ロギングライブラリを使いたければ、特にJavaの世界にはLog4j, JCL, slf4j, logbackなど多くのものが存在する。私はslf4jとlogbackを組み合わせて使うのが好きだ。とてもパワフルで、設
我々は Kubernetes の何を監視すればいいのか？ / CloudNative Days Kansai 2019
我々は Kubernetes の何を監視すればいいのか？ / CloudNative Days Kansai 2019
Kuberntes Monitoring 入門 - Speaker Deck
QA出身スリーアミーゴスでDeep Dive! スクラムで品質とスピードを意識したOne Teamを構成するために必要だったもの / Deep Dive into the the Essence of 'One Team'
Operating a Large, Distributed System in a Reliable Way: Practices I Learned
For the past few years, I've been building and operating a large distributed system: the payments system at Uber. I've learned a lot about distributed architecture concepts during this time and seen first-hand how high-load and high-availability systems are challenging not just to build, but to operate as well. Building the system itself is a fun job. Planning how the system will handle 10x/100x t
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostgreSQL Architecture And Performance Monitoring
PCI DSS準拠から学ぶサステナブルなAWSクラウドネイティブの運用 / Sustainable PCIDSS operation on AWS
