様々なrate limitアルゴリズム - Carpe Diem
概要 インターネットに晒されているWebサービスでは TV等で紹介されたことによる大量流入 悪意ある人物からの攻撃 クライアントのバグに依る大量リクエスト など、本来想定していた以上のトラフィックが来ることはよくあります。 単純にシステムを構築すると大規模トラフィックに対応できずシステムがスローダウンしてしまうため、何かしらrate limitをかけておいた方が良いです。 ただしrate limitと一口に入っても色々あるため、今回は主なrate limitアルゴリズムを紹介します。 Leaky bucket Leaky bucketはデータ転送レートを一定にする（＝上限を設定する）アルゴリズムです。 下の図のように、様々な流量の水流がそのバケツに流れ込んでも小さな穴からは一定の水流が流れ出す仕組みです。 ref: What is the difference between token
Goのnilについて - Carpe Diem
概要 先日の golang.tokyo #6 - connpass で独自のエラー型でnilにハマった点に触れられていて、自分でもふわっとしか覚えてなかったのでまとめ。 覚えること 以下を覚えておけばとりあえず大丈夫です。 nilは型を持つ interfaceの場合のみ、型もnilでないとxxx == nilはfalse nilを扱う型は pointer function map slice channel interface がありますが、注意するのはinterfaceのみで大丈夫です。 解説 nilは型を持つ nilは型と値の２つを持ちます。 func main() { var i32 *int32 fmt.Println(reflect.ValueOf(i32).IsNil()) // true fmt.Println(reflect.TypeOf(i32)) // *int32 v
goroutineはなぜ軽量なのか - Carpe Diem
概要 以前の記事で christina04.hatenablog.com Goはスレッドよりはるかに軽量なgoroutineでC10K問題を解決する、という話をしましたが、goroutineが軽量なのはなぜか？という理由を深掘りしたことがなかったのでしてみました。 環境 golang 1.11.1 Darwin 17.7.0 軽量と呼ばれる理由は２つ 大きく分けると以下の２つのポイントがあります スレッドに比べてメモリ使用量が低い スイッチングコストが低い それぞれ説明していきます。 goroutineがスレッドに比べてメモリ使用量が低いのはなぜか スタックとヒープのメモリの使い方を理解すると分かります。 ヒープはメモリの下層、プログラムコードのすぐ上にあり、上に向かって成長します。一方スタックは仮想アドレス空間の一番上にあり、徐々に下に成長していきます。 ref: イベントループなしでの
SPAを S3+CloudFront で表示する方法 - Carpe Diem
概要 AngularなどのSPAをS3+CloudFrontで表示する方法についてです。 要件 SSL/TLSを使いたい https://example.com/hoge のようなサブディレクトリのようなパスで403にならないようにしたい ↑のようなパスでもOGPがきちんと表示される リロードしても404にならない S3バケットのファイルには直接アクセスできないようにしたい 以前のケースとの比較 過去に S3 + CloudFrontにした時にハマったこと - Carpe Diem Angularで作ったサイトでリロードすると404エラー - Carpe Diem で似たようなケースに対応しました。しかしこれらは先の要件である 3. ↑のようなパスでもOGPがきちんと表示される や 5. S3バケットのファイルには直接アクセスできないようにしたい を満たせていませんでした。今回はそちらを考
ECSのオートスケール戦略 - Carpe Diem
概要 ECSはコンテナのスケールアウトとインスタンスのスケールアウトのタイミングが重要です。 よく起きる問題としては インスタンスのスケールアウトが遅くてコンテナのスケールアウトも遅くなってしまう しきい値が不適切でインスタンスがスケールアウトせず、コンテナがスケールアウトしたくてもできない で、こういった事が起きないようにしないといけません。 スケールアウトの方針 対象 方針 インスタンス インスタンスの空きリソースがコンテナ１台分だけの状態がｎ分間続いたら コンテナ コンテナの使用率がｎ%を超えたら インスタンスはもう１台もコンテナを追加するリソースがない状況になったら早めにスケールアウトします。 コンテナは一般的なやり方で使用率が高くなったらスケールアウトすればOKです。 スケールインの方針 対象 方針 インスタンス コンテナがｎ分間ずっと１台を下回ったら コンテナ コンテナの使用率
B TreeとB+ Treeの違い - Carpe Diem
概要 インデックスに対してMongoDBはB Treeを採用し、MySQLのInnoDBはB+ Treeを採用しています。 どうして採用しているアルゴリズムが違うのだろう？と思って調べてみました。 主な違い B+ TreeはほとんどB Treeと同じですが、以下の点が異なります。 リーフノードとリーフノードを結ぶポインタがある データはリーフノードのみに保持する 具体例 言葉だけだと分かりにくいので、Visualizeするツールを使って具体例を表示します。 [1, 2, 3, 4, 5, 6, 8, 10, 15, 18]という数列に対し、Order: 3で作ってみます。 Orderは１ノードから出る枝の数のことです。 B Tree B-Tree Visualization B+ Tree B+ Tree Visualization 先程のB Treeと違って、データはリーフノードに持つの
remote_addrとかx-forwarded-forとかx-real-ipとか - Carpe Diem
背景 ECSでNginxのコンテナをプロキシとして立てたところ、APIサーバのアクセスログのクライアントIPがNginxのコンテナIPになっていたのでその修正をしたのがきっかけです。 環境 Nginx 1.10.2 Docker1.12.1 構成 Client -> ELB -> Nginx -> API という構成とします。 ネットでよく見る情報 set_real_ip_from 172.31.0.0/16; real_ip_header X-Forwarded-For; を追加する、とか proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; を追加する、とかどれがどれだか分かりにくいので１つ１つ説明していきます。 用語説明 remote_
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
