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
Rails アプリケーションの不安定なテストを撲滅したい 〜system spec のデバッグ方法とテストを不安定にさせる要因〜
Rails アプリケーションの開発において、自分の変更に関係のないテストのせいで CI がコケるとストレスですよね？真っ先に直したくなりますよね？不安定なテストを直すのは大変な労力が要ると思ってませんか？実は、たいていのケースは簡単に再現確認ができるし、不安定になる要因もだいたい決まっているし、ログやスクリーンショットを見れば原因も簡単に特定できるんです！ そんなわけで、日頃不安定なテストを潰している身として知見みたいなものをまとめてみました。 今回利用した環境は次のとおりです。 rails 6.0.0 capybara 3.29.0 selenium-webdriver 3.142.4 rspec-rails 3.8.2 Google Chrome 77.0.3865.75 (headless で使用) ChromeDriver 77.0.3865.40 (f484704e052e0b5
Fluentd 入門 〜運用に必要な基礎知識〜
最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ？」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ！」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En
私的アンリーダブルコード―他人を発狂させるための 9 のテクニック
コードはたいてい一度しか書かれませんが、何度も何人も読むことになります。 普段何気なく書いているコードが他人の時間と精神を削っているかもしれません。 そんなわけで、個人的に辛いなと思うことを 9 つ挙げてみました。共感してもらえるものもいくつかあるんじゃないかと思います。 実体にそぐわない変数名 見分けの付かない配列とハッシュの変数名 呼び出し元で true/false を指定するだけの引数 暗黙の実行順序 [] メソッドの定義・Array の継承 ハッシュの乱用 密結合した mixin 過剰な nil guard 条件によって異なる返り値の型 推薦図書 静的型付き言語を使うことで解消される問題もありますが、その選択肢はひとまずなしということで。 Ruby 前提になっていますが、他の言語にも言えることも多いと思います。 実体にそぐわない変数名 例えば Vehicle というクラスが定義され
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
