ホストメトリックの異常検知を行なうmackerel-agentのチェックプラグインを作りました - yasuhisa's blog
最近、異常検知の実験/実装を行なっていますが、その過程の中間成果物をmackerel-agentのチェックプラグインとして切り出しました(非公式のプラグインです。サポート宛てにお問い合わせしてもらっても回答できません。id:syou6162まで個人的に連絡してもらえたら対応できるかもしれません)。docker pull yasuhisa/check-host-metric-anomalyで簡単に使えるので、是非遊んでみてください。 syou6162/check-host-metric-anomaly: Mackerelのホストメトリックの異常検知を行なうチェック監視プラグイン yasuhisa/check-host-metric-anomaly - Docker Hub このチェックプラグインの使いどころは ホスト監視をしたいが、どれくらいの閾値が適当なのか分からない/閾値の調整が面倒なの
Cloud Spanner と CAP 定理 | Google Cloud 公式ブログ
グローバルに分散化されたデータを扱い、データの一貫性を維持しながら高可用性をも実現するシステムを構築しようとしたら、それは簡単なことではありません。クラウドの良いところは、誰かがそれを構築して、誰にでも使えるようにしてくれることです。 CAP 定理によると、データベースは以下の 3 つの望まれる特性のうち、2 つまでしか持てないとあります。 C（Consistency）: 一貫性、共有されているデータが唯一の値を持つ A（Availability）: 可用性、読み込みと書き込みの両方で 100% の可用性が確保されている P（Partition Tolerance）: 分断耐性、ネットワークの分断に対する耐性があるここから導かれるシステムは 3 種類で、除く文字に応じて CA、CP、AP となります。これは、システムの設計者に 3 つから 2 つを選ぶことを強いるものではなく、実際多くのシ
uniq を少し早く処理するツール "quniq" を作った - ブログ・ア・ラ・クレーム
TLDR 重複行を除去する uniq コマンドを早く実行するツール "quniq" を Go で作ってみました。 github.com 自分が測った限りでは、他の重複除去を行なうワンライナーと比べて、処理に要する時間が少なくとも 1/3 程度になることが確認できました。 背景 みなさまご存知の通り、 uniq はソート済みの入力を受け付けて重複行を除いた出力を吐き出すツールです。 また -c オプションで重複件数も出力したりすることが可能です。 特に集計の前処理として余分な行を除外したり、アクセスログ中の特定要素のランキング化に利用されることが多いように感じます。 uniq はソート済みの入力を期待するためよく cat /path/to/file | sort | uniq のように sort した結果をパイプで渡すことが多いと思うのですが、入力のサイズが大きくなってくると sort に時
コスト効率の悪いLambdaアプリケーションの性質に関する考察 - ゆううきブログ
概要 Lambdaは100msの実行時間単位でオンデマンドに課金されるため、立ち上げっぱなしのEC2インスタンスよりも、料金が安くなる可能性があることが一般に知られている。 しかし、以下の性質を満たすアプリケーションでは、EC2インスタンス上に構築したケースと比較して、Lambda上に構築したほうがコスト効率が悪くなるのではないかと考察してみた。 Lambda functionの実行時間のうち、ネットワークI/O時間が支配的である Lambda functionの実行終了を同期的に待たなければならない 複数のレコードをLambda functionの引数に渡すことができない Lambdaの基本コスト構造 まず、Lambdaのコスト構造を把握する。 Lambdaの料金表[1]によると、「functionに対する合計リクエスト数」と「functionの合計実行時間」に応じて料金が発生する。 後
Serverlessconf Tokyo 2017で『サーバレスアーキテクチャによる時系列データベースの構築と監視』という発表してきました - プログラムモグモグ
先日開催されたServerlessconf Tokyo 2017にスピーカーとして参加しました。 2017.serverlessconf.tokyo Mackerelの今の時系列データベースは、マネージドサービスを組み合わせて作っています。 検証・実装・投入フェーズを終えて、運用・新機能開発フェーズに入っています。そんな中で、監視サービスを提供する私たちが、サーバーレスアーキテクチャで作ったミドルウェアをどのように監視しているかについてお話しました。 何かしら役に立つことや発想の元となるようなことをお伝えできていたらいいなと思います。 私も他の発表から様々なことを学びました。特に面白かった発表を挙げておきます。 真のサーバレスアーキテクトとサーバレス時代のゲーム開発・運用 ゲーム開発を支えるBaaSを開発されるなかで得られた様々な知見についてお話されていました。 プッシュ通知のために大量の
AWS の CPU の歴史とそこから見えてくる戦略 | はったりエンジニアの備忘録
あけましておめでとうございます！ 去年は AWS 認定試験を制覇したので、今年は実践スキルを今以上に磨いていこうと思います。 さて、最近の EC2 インスタンスは Intel CPU のプロセッサー・ナンバーが公開されています。ですが M1, M2, C1 といった旧世代インスタンスでは CPU にばらつきがあり、当たり外れの差が激しかったのは記憶に新しいところ。 当たりの CPU が出るまで stop → start を繰り返すインスタンスガチャも流行りました (笑) 今回は AWS の CPU について歴史を振り返りつつ、その戦略を考えてみます。物理レイヤーを意識することがほとんどない AWS ですが、物理の知識なしでは最高のパフォーマンスは得られません。知っておいて損はないでしょう。 インスタンスタイプのリリース時期は公式ブログ「EC2 の歴史」に載っていますので参考にしてください。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
