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
モダンなシステムにSLI/SLOを設定するときのベストプラクティス
New RelicではどのようにSLI/SLOを定義し、SREを実践しているか。その経験から、SLI/SLOについて解説した記事 Best Practices for Setting SLOs and SLIs For Modern, Complex Systems の翻訳です。 -- New Relicのサイト信頼性VPであるMatthew Flamingも、この記事に貢献しています。この記事はサンフランシスコその他で行ったFutreStack18での講演「SLOs and SLIs In The Real World: A Deep Dive.」をもとに作られています。 New Relicでは、サービスレベル指標（Service Level Indicator: SLI）とサービスレベル目標（Service Level Objective: SLO）を定義したり設定したりことが、サイト
Kubernetes 上のアプリケーションから Stackdriver Logging に構造化ログを送る - スタディサプリ Product Team Blog
SRE チームの @yuya-takeyama です。 Quipper の SRE チームでは AWS や Kubernetes を用いたインフラの構築、CI/CD パイプラインの構築・改善等様々な Developer Experience の向上、社内のあらゆるサービスのマイクロサービス化のサポート、そしてそれに伴う複雑化にも耐え得るよう、サービスの安定稼働を支えるためのルール・ツール群を整備しています。 今日はその中でも、簡単かつより精緻に Logs-Based Monitoring が行えるよう、GCP の Stackdrider Logging に構造化ログを送る方法について紹介します。 構造化ログとは ここではとりあえず「Machine-Readable なログ」として定義します。通常のログはテキストベースの Human-Readable なもので、UNIX 哲学においては行指向
メンテナンスウィンドウを使わない - @katzchang.context
6年ほど無停止のサービスを運用してきた私の経験からすると、メンテナンスウィンドウ、つまり計画的メンテナンスに対するアラート発砲を抑制する機能は、使わないほうがうまくいく。仕事の中でも度々メンテナンスウィンドウの話題が出てきたので、個人の見解としてまとめてみたい。 計画的メンテナンスの手順 対外的に無停止だとしても、内部的には停止を伴うメンテナンスをすることがある。たとえば、MySQLを止めることはたまにある。まずは、どのようにメンテナンスを進めていくのかを整理しよう。 内部的な停止を伴うメンテナンスの際は作業に必要な時間とともに、アラートが起こる範囲を予測し、予告しておく。予告の範囲を決めるのは単純で、アラートが届くだろうチャンネルにお知らせしておけばいい。以前のチームではメールとSlackチャンネルを使っていたので、そこに書いていた。準備はこれでいい。 メンテナンス作業が始まる（たとえば
いま知っておきたいLinux─WebアプリがOSのプロセスとしてどのように見えるか？ を運用に生かす｜ハイクラス転職・求人情報サイト AMBI（アンビ）
いま知っておきたいLinux─WebアプリがOSのプロセスとしてどのように見えるか？ を運用に生かす Webアプリを動かして負荷をかけると、OSのプロセスという観点ではどのように見えるのでしょう？ それを通して運用やトラブルシューティングではどういったことが分かるのでしょう？ Linuxカーネルの開発者でもある武内覚（sat）さんによる解説です。 こんにちは、sat（@satoru_takeuchi）と申します。 コンピュータが誕生してから現在まで、最終的にエンドユーザが意識するアプリケーション開発はどんどん楽になっています。先人たちのたゆまぬ努力の結果、アプリ開発者はOSや、そのさらに下にあるハードウェアのことをほとんど意識することなく開発ができるようになりました。 しかし、「作ったアプリが、OSレベルでどのように動いているか？」が今一つピンと来なくて、モヤモヤしていないでしょうか。それ
ラズパイとWebRTCで動物の死活監視ができるようにした話 - ( ꒪⌓꒪) ゆるよろ日記
こんにちわ、しいたけです。 今は夏休みで奥さんと子どもたちが帰省しているので、動物と2人で暮らしています。 で、外出すると動物だけを家に残していくことになります。 ペットモニターとか市販でもあるんですが、せっかくなので、 夏休みの自由研究として、ラズパイ+カメラモジュールとWebRTCを使って、外出先からでも動物の状態を確認できるやつを作ってみました。 ↑ 死活監視される動物の様子です 用意したもの Pi3 B+ スターターキット V3 16GB 白 Piカメラ Official V2 for 3/2/1/0 Manfrotto ミニ三脚 PIXI ブラック MTPIXI-B カメラ用 Manfrotto スマートフォン用三脚アダプター MCLAMP HAKUBA 自由雲台 BH-1 ラズパイ3とケースのセットとカメラモジュールは Raspberry Pi Shop by KSY で購入。
自動障害回復システム 月読の話 - Cybozu Inside Out | サイボウズエンジニアのブログ
@ymmt2005 こと山本泰宇です。短い夏休みから帰ってきました。 今回は cybozu.com のデータセンターで運用を開始した自動障害回復システム「月読」を紹介します。障害にも色々ありますが、今回紹介するのは仮想マシンのホストサーバーの物理障害を検出して、稼働していた仮想マシンを予備のホストに移動する仕組みです。 月読は、データセンター全域に分散したエージェントが協調動作するピア・ツー・ピア (P2P)システムとして作られています。以下分散システムの話題が多数でてきますが、とても難解というわけではないので、分散システムの入門記事としてお楽しみください。 障害にどう対処するか 障害対応の自動化 設計のポイント エージェント間通信 障害の検出と回復 その他の機能 まとめ 障害にどう対処するか 物理障害対策の基本は二重化(多重化)です。アプリケーションサーバーのようにデータを持たないサーバ
Foreman
Provision from anywhere Bare metal (MaaS), Amazon EC2, Google Compute Engine, OpenStack, Libvirt, oVirt, VMware, and many other providers allow you to manage a hybrid cloud through Foreman. Configuration An external node classifier, hiera-like parameters, and reports monitoring for Puppet and Salt are included. Completely ready to tweak host groups in your data center. Monitor hosts Foreman report
DNS over HTTPSを使ってDNSレコードを外形監視 - LIVESENSE ENGINEER BLOG
こんにちは、インフラグループの水野です。 みなさん、DNSのレコードの監視を行っていますか？ DNSレコードの変更ミス等を検知することはもちろん、自分たちの運営しているサービスの名前解決がユーザ側でどのように見えているのかというのを確認することは大切です。 しかしながら、DNSレコードを外形監視してくれる監視ツールは数が少なく中々コレといったものがありません。 外部からの監視をしたいがためにパブリッククラウドに監視専用のインスタンスを建てるのももったいないです。 弊社ではメインの監視ツールとして Mackerel を利用していますが、MackerelにはURL外形監視はありますが、DNS外形監視はありません。 別途 pingdom のDNS外形監視を利用していましたが、pingdomではIPアドレスとのマッチしかできません。 IPアドレスもひとつしか登録できないため、ELBのようにIPアド
maprobe - Mackerel のホスト情報と連携する外形監視エージェントを作った - 酒日記 はてな支店
監視を Zabbix から Mackerel に移行しています。そこで困ったことを OSS を書いて解決しようシリーズのお時間です。 ホストのダウン検知を早くしたい Mackerel の監視は Push 型と呼ばれるもので、mackerel-agent が Mackerel サーバに対してメトリクスを送信する形態です。そのため、agent を稼働させているホストがダウンしたという事象は、「一定時間サーバに対して情報が送られてこない」ことによって、組み込みのアラート "connectivity" として検知されます。 これによって困ることとしては、以下があります。 ホストが実際にダウンしてから7分程度経過しないとアラートが上がらない あまり短時間で判断してしまうと誤検知が増えるからでしょうか もうちょっと早く検知したいです "connectivity" アラートは Critical レベルし
sardine で mackerel-plugin の出力をサービスメトリックとして投稿する - 酒日記 はてな支店
全国三千万 Mackerel ユーザーの皆様こんにちは。 mackerel-plugin で生成した値を、サービスメトリックとして投稿したいと思ったことはないでしょうか。ありますよね。でも mackerel-agent ではホストメトリックしか投稿できません。 ということで、拙作の sardine に Mackerel のサービスメトリックとして投稿する機能を追加しました。(Thanks for @jet_zousan) sardine についてはこちらをご覧ください。 sfujiwara.hatenablog.com github.com mackerel-plugin 互換の出力を CloudWatch のメトリックとして投稿する agent です。 おもにコンテナ環境で、mackerel-agent を全部に立てたくはないけど使い慣れた mackerel-plugin で収集した値を
【Percona Live 2017】イベントレポート：Percona社イチ押し!?のPMM | db tech showcase
【Percona Live 2017】イベントレポート：Percona社イチ押し!? 監視ツール『Percona Monitoring and Management』 『Percona Monitoring and Management (通称PMM)』は前回のPercona Liveでは1コマほどしか紹介されなかったようですが、今回のPercona Liveでは複数のセッションにわたり紹介されて、Percona社CEO Peter Zaitsev 氏も自らセッションを開いて推していたパフォーマンス監視ツールです。MySQLやMongoDBなどのDBと各エンジンに対応しており、Amazon RDS環境への監視にも対応しているとのこと。 「Grafana ()」というWebベースのダッシュボードソフトを使用しており、レイアウトや監視項目のカスタマイズが可能で、標準の監視項目としてOSのリソー
Datadog による Container の監視について
社内で行った Datadog 勉強会の資料になります。 下記の内容について簡単に説明してあります。 ・Datadog でコンテナ監視を行なう場合の基礎知識 ・Datadog で Kubernetes 監視を行なう方法 ・Kubernetes add-on の kube-stete-metrics を使ったクラスタレベルメトリクスの監視 ・helm を使った datadog の all-in-one 1 コマンドデプロイ ・2 sec 間隔で行われるライブコンテナモニタリング ・auto_conf を使ったコンテナディスカバリ
Monitoring Seminar in mercari を開催しました - Mackerel お知らせ #mackerelio
mackerelio.connpass.com 11月29日（水）、はてなとメルカリにおけるモニタリング事例をご紹介する"Monitoring Seminar in mercari"を開催しました。 今回は六本木ヒルズにあるメルカリ様のイベントスペースをお借りして、多くの方々にご来場いただきました。 会場を提供していただいたメルカリ様、ご来場いただいた皆様、本当にありがとうございました。 メルカリのシステム・サービス監視について 最初のセッションはメルカリの長野さんです。 前半ではメルカリにおけるモニタリングツールの歴史と運用について、後半ではMackerelでの監視項目をご紹介いただきました。 実際にどのような監視を行なっているのか、みなさん興味深く聴いておられました。 「メルカリのシステム・サービス監視について」セッションの様子 Microservices Monitoring at
karky7のブログ: iotopが意外といいんじゃないか
IOのread、writeがプロセスごとに取れる ゴールデンウィーーークもそろそろ終了、アルチューハイマーになったこの体を元にもどすのに、リハビリが必要な時期に...どうでもいいですが... いきなり話、違う話 iostatとかでも取れるんだけど、デバイスごとのIOの統計が上がってくるので、もうちょい細かいレイヤーでそれが見たいときがある。なんか無いかとportageツリーをさまよっていたら、iotopなるものをを発見。 カーネルのオプションが多分必要なので、確認してね CONFIG_TASK_IO_ACCOUNTING CONFIG_TASK_DELAY_ACCT CONFIG_TASKSTATS CONFIG_VM_EVENT_COUNTERS で、iotopをインストール cuomo@ugui7 ~ $ emerge sys-process/iotop 暇なので、kernelの方も覗
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How we monitor microservices at Mercari microservices platform team
TechCrunch
Open-Falcon - Monitoring system & time series database
What has been realized to improve maintainability at "Eight".
Monitoring at AbemaTV
