タグ

ブックマーク / abicky.net (14)

  • Datadog メトリクスモニター作成入門

    Datadog はモニタリング関連の SaaS ではおそらく最も利用されているサービスでしょうが、公式ドキュメントが豊富にある割には何から読み始めれば良いかわかりにくく、慣れるまでの道が険しい印象です。 エントリーでは、Datadog が既に導入されている組織で、Datadog モニターを使って監視をしたいけど、モニターの設定方法がよくわからないといった方を対象に、メトリクスモニターの作成に焦点を絞って解説していきます。なお、あくまで Datadog の使い方についての解説であり、どのようなモニターを設定すべきかについては触れません。 メトリクスの収集についても触れたかったんですが、力尽きたので、メトリクスの収集については気が向いたら別エントリーを書きます。 アジェンダ メトリクスモニターの作成方法の基 クエリの定義について クエリの評価期間・評価方法・アラート条件の指定 クエリの結果

    Datadog メトリクスモニター作成入門
  • Takeshi Arabiki

    Takeshi Arabiki 自己紹介 SRE とデータエンジニアリングとアプリケーション開発を足して 2(not 3!)で割ったような役割のチームでテックリードとプレイングマネージャーを足して 2 で割ったようなことをしているエンジニア。主に Rails / AWS / MySQL / Presto / Fluentd / Cassandra / Kafka。R言語上級ハンドブック(2013 年)共著者。 関連 URL 個人ブログ @a_bicky abicky abicky Speaker Deck a_bicky クックパッド開発者ブログ執筆エントリー Repro Tech Blog 執筆エントリー 社内インタビュー 不可能に見えても諦めない。納得できるまで追求すれば、いつか技術は血肉になる。 - Repro culture (2020 年) エンジニアリングを超えた、企画もできる

    Takeshi Arabiki
  • カランメソッドの全ステージを修了した

    先日、カランメソッドの全ステージを修了しました。約 2 年という長い道のりになりましたが、最後までやり切ることができて一安心です。良い機会なのでカランメソッドについて振り返ってみます。 カランメソッドを始めたきっかけ 元々英語の勉強を始めたきっかけは re:Invent 2019 に参加することになったからでした。英語ができなくても十分楽しめると言っている人もいますが、より有意義な時間を過ごすためにも英語を勉強することを決意しました。当時は YouTube 広告で知った ENGLISH COMPANY に 2 ヶ月ほど通い、その後 2 週間程度 DMM 英会話英会話の練習をしました。 ところが結果は次のように散々でした。 ブースを一人で回っても相手が何を言っているかほとんどわからなかったし、聞きたいことも聞けなかった 現地の方との懇親会的なものがあったが、相手が何を言っているかほとんどわ

    カランメソッドの全ステージを修了した
  • Rails Developers Meetup 2018 で「MySQL/InnoDB の裏側」を発表しました

    Rails Developers Meetup 2018: Day 1 で「MySQL/InnoDB の裏側」と題して SELECT クエリの実行フローや InnoDB のインデックス周りの発表しました。MySQL with InnoDB のインデックスの基礎知識とありがちな間違い + α の内容です。 Nested Loop Join のスライドは無理やり差し込んだ感が溢れてますがご了承ください>< 追記: 動画も公開されたので貼り付けておきます。1 key_len について発表で全然触れなかったんですが、重要な内容なので次のエントリーにまとめました。 MySQL で複合インデックスを作成する際には必ず key_len を確認すべきという話 補足 サンプルデータ MySQL のサンプルデータとしては world や employee が有名だと思うんですが、前々から world は物足り

    Rails Developers Meetup 2018 で「MySQL/InnoDB の裏側」を発表しました
  • Amazon Elastic MapReduce (EMR) ではじめる Presto/Trino 入門

    Presto/Trino 1は日語の入門書がなく、「Presto/Trino を運用することになったけど何から勉強すれば良いかわからない><」という人も多いのではないかと思います。そこで、Presto/Trino を運用する時にこの辺の内容を知っていれば、よりスムーズにキャッチアップできたかなぁと思うことをまとめてみました。 Hive connector を使いたいので、Hive と Presto の環境構築をサクッと行える Amazon Elastic MapReduce (以降 EMR) で実際に手を動かせればと思います。 以降 Presto/Trino ではなく Presto と表記しますが、Trino は元々同じソフトウェアであるため、Trino でも当てはまる内容がほとんどのはずです。 なお、Presto のバージョンは 2019-03-13 時点で最新の EMR 5.21.0

    Amazon Elastic MapReduce (EMR) ではじめる Presto/Trino 入門
  • 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

    Amazon SQS を使ったアプリケーションを本番で運用する際に考慮すべき基本的な 5 つのこと
  • Docker のログを columnify で Athena (Presto) に特化した Parquet にする

    先日 columnify という、入力データを Parquet フォーマットに変換するツールがリリースされました。 cf. 軽量な Go 製カラムナフォーマット変換ツール columnify を作った話 - Repro Tech Blog また、fluent-plugin-s3 で compressor として columnify をサポートする話が出ています。1 cf. Add parquet compressor using columnify by okkez · Pull Request #338 · fluent/fluent-plugin-s3 個人的に前々から Docker のログを Parquet フォーマットで S3 に put して Athena で検索できると素敵だなと思っていたので喜ばしいことですね!そんなわけで、Docker のログを fluentd log dr

    Docker のログを columnify で Athena (Presto) に特化した Parquet にする
  • 171937

    日頃の業務で複数台のサーバにログインしてオペレーションすることがあると思うんですが、cssh, i2css, tmux-css, xpanes 等便利なツールがあるし、tmux 関連の簡易スクリプトだけでも次のように色々見つかります。 もっと簡単に!tmuxで複数のサーバにSSH接続して同じコマンドを一気に送る | 三度の飯とエレクトロン tmuxで複数サーバの同時オペレーション – NaviPlus Engineers’ Blog tmux + ssh + Mackerel API を組み合わせたとにかくモダンなサーバオペレーション - ゆううきブログ tmux は even-horizontal, even-vertical, main-horizontal, main-vertical, tiled という layout が用意されていて、どのスクリプトもこのいずれかを使っています。

    171937
  • Amazon SQS の ApproximateAgeOfOldestMessage とは何なのか?

    SQS には ApproximateAgeOfOldestMessage という、queue に存在する最も古いメッセージの、queue に入ってからの経過時間に関するメトリクスがあります。例えば queue の処理が遅延していることを検知したい場合、ApproximateNumberOfMessagesVisible よりも良い指標となる場合があります。ただ、このメトリクスの定義の詳細についてはドキュメントに載っておらず、ドキュメントに書かれている内容も正確さを欠くので実験を通して現在の挙動についてまとめてみました。 実験結果等を踏まえた ApproximateAgeOfOldestMessage の定義 結論から述べると、次のような定義と言えます。 メトリクスの対象メッセージは queue に存在するすべてのメッセージであり、invisible なものも含む メトリクスの値は queu

    Amazon SQS の ApproximateAgeOfOldestMessage とは何なのか?
    t2y-1979
    t2y-1979 2020/05/21
  • commit をどう分割すべきか 〜コードレビューの観点から〜

    普段の開発の中で git の commit の単位に気を遣っている人もいると思うんですが、どういう単位で commit すべきかみたいな話をあまり見かけない気がします。自分自身 GitHub の Pull Request(以降 PR)ベースのチーム開発を何年か経験してみて、「こうすると良さそう」というものが見えてきた気がするのでまとめてみました。 なお、小さい単位で PR を出す方針にしている場合は、以降の内容に出てくる commit を適宜 PR で読み替えてもらうと良いかもしれません。 そもそも commit の単位に気を遣った方が良いのか? コードレビューを行う場合など、他者がコードを読む場合はある程度気を遣った方が良いと思っています。理由は次のとおりです。 コードレビューにおいてレビュアーのレビュー時間が短縮できる コードレビューの精度が上がる 変更の経緯を追いやすい 自分にとって

    commit をどう分割すべきか 〜コードレビューの観点から〜
  • Cassandra でレプリケーションストラテジーを変更するとデータが消失する

    Cassandra でレプリケーションストラテジーを変更するとデータが消失する現象に遭遇したんですが、どうしてそんなことが起きるのかやどうしたら直せるのかがさっぱりわからなかったので、ソースコードを読んだり手を動かしたりして調べてみました。 以下、Cassandra 3.11.4 の話です。 partitioner としてデフォルトの Murmur3Partitioner を使用し、endpoint snitch として GossipingPropertyFileSnitch を使用することとします。 Cassandra のレプリカノードはどのように決まるのか? まず、そもそも Cassandra がどのようにレプリカノードを選択しているかがわからなかったので、それについて説明します。 データセンターの数が 1、ラックの数が 2、ノード数が 3 の次のようなクラスタを考えます。 IP Ad

    Cassandra でレプリケーションストラテジーを変更するとデータが消失する
  • 一定間隔の滞在ユーザ数を高速に求める Presto SQL - あらびき日記

    Presto でどのような SQL を書いたらこれを高速に求められるかというお話です。 データは S3 に置くことにするので、試したい方は Athena や Amazon Elastic MapReduce (EMR) を使うとサクッと確認できます。 サンプルデータ 次のような Ruby スクリプトで S3 にデータをアップロードします。例えば、環境変数 S3_LOCATION に s3://example.com/test を指定すると、s3://example.com/test/access_logs 以下と s3://example.com/test/time_ranges 以下にデータがアップロードされます。 require 'date' require 'uri' require 'aws-sdk-s3' BASE_DATE = Date.parse('2018-12-01')

    一定間隔の滞在ユーザ数を高速に求める Presto SQL - あらびき日記
  • Presto における Service Discovery の動作原理

    Presto を運用していると “No worker nodes available” というエラーに遭遇することがあります。これは coordinator が planning をする際に active な worker nodes が存在しないと起きるエラーなんですが、worker nodes に問題ではなく service discovery が上手く機能していなくて起きることがあります。 worker nodes が異常なのか service discovery が上手く機能していないのかを切り分けるには、Presto がどのように service discovery を実現しているかを理解している必要がありますが、よくわかってなかったので調べてみました。 環境は Amazon Elastic MapReduce (EMR) ではじめる Presto 入門と同じく、Presto 0

    Presto における Service Discovery の動作原理
  • upstart で start した job の設定を変更するには一度 stop する必要がある

    upstart で start した job の設定を変更した後に反映するには、次のように stop して start しなければいけません。restart ではダメです。restart でダメな理由は後述します。 upstart は inotify で設定ファイルのディレクトリを監視しているのでわざわざ initctl reload-configuration を実行しなくてもいいんですが、FAQ を読む限り「読み込むとは言ったが反映するとまでは言ってない」という感じみたいですね…。 Upstart uses inotify to watch the configuration directory for changes, there’s no need to force it to read the job definition again. If a job is running,

    upstart で start した job の設定を変更するには一度 stop する必要がある
  • 1