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
SRE Lounge #11 で「安定・安価なECS auto scalingを目指して」を発表しました
SRE Lounge #11 で Repro で行っている ECS の auto scaling について発表しました。ECS autoscaler で工夫している点についてがメインですが、一般的な auto scaling にも使える知見もあるかと思います。 補足 時間の都合上、発表で言及しなかったこともあるので補足です。 ECS_ENABLE_SPOT_INSTANCE_DRAINING について 発表でも軽く触れましたが、ecs-agent 1.32.0 以降を使っている場合、ECS_ENABLE_SPOT_INSTANCE_DRAINING パラメータに true を指定することで、spot instance の interruption warning (notice) を受け取った場合に勝手に draining 状態にしてくれます。 cf. Amazon ECS support
ECS の Enhanced Container Dependency Management でタスク終了時のコンテナの依存関係を考慮する
先日次のような記事を書きました。 ECS タスクの終了時にコンテナの依存関係が考慮されない問題を解決するコマンドを作った [ECS] [Proposal]: Container Ordering · Issue #123 · aws/containers-roadmap が導入されるまでの役目となるでしょうが、同じような悩みを抱えている人のお役に立てば幸いです。 その約 2 週間後に ecs-agent v1.26.0 がリリースされ、コンテナの依存関係を記述できるようになりました。 cf. Amazon ECS Introduces Enhanced Container Dependency Management Pull Request はこちら https://github.com/aws/amazon-ecs-agent/pull/1904 ecswrap が約 2 週間でお役御免
ECS タスクの終了時にコンテナの依存関係が考慮されない問題を解決するコマンドを作った
ECS タスクは、起動時にはコンテナの依存関係を考慮するのに終了時は全く考慮しません。次のコメントからもよくわかります。 A container can always stop, die, or reach whatever other state it wants regardless of what dependencies it has cf. agent/engine/dependencygraph/graph.go#L179-L180 これの何が問題かというと、fluentd のようなデータ収集用のサイドカーコンテナが動いている場合に、メインのコンテナよりも先にサイドカーコンテナが停止してデータが消失するということが起きてしまいます。 このことは 2 年半前から issue に上がっているんですが、未だに解決されていません。 cf. Termination order of li
commit をどう分割すべきか 〜コードレビューの観点から〜
普段の開発の中で git の commit の単位に気を遣っている人もいると思うんですが、どういう単位で commit すべきかみたいな話をあまり見かけない気がします。自分自身 GitHub の Pull Request（以降 PR）ベースのチーム開発を何年か経験してみて、「こうすると良さそう」というものが見えてきた気がするのでまとめてみました。 なお、小さい単位で PR を出す方針にしている場合は、以降の内容に出てくる commit を適宜 PR で読み替えてもらうと良いかもしれません。 そもそも commit の単位に気を遣った方が良いのか？ コードレビューを行う場合など、他者がコードを読む場合はある程度気を遣った方が良いと思っています。理由は次のとおりです。 コードレビューにおいてレビュアーのレビュー時間が短縮できる コードレビューの精度が上がる 変更の経緯を追いやすい 自分にとって
Fluentd 入門 〜運用に必要な基礎知識〜
最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ？」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ！」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
