go-redisのRingの挙動を検証してみる - Carpe Diem
概要 Redis Clusterが生まれるまではRedisの水平スケール手段としては前回紹介した Consistent Hashing （コンシステントハッシュ法） - Carpe Diem を用いた手法が使われていました。 これはRedis Ringと呼ばれる形でいくつかのライブラリでサポートされており、Goでもgo-redisでサポートされているので検証してみました。 環境 Redis v6.2.6 Go v1.7.2 go-redis v8.11.4 検証 構成 以下のような独立したRedisサーバ３台に対してConsistent Hashingで分散アクセスします。 docker-compose.yml 上記構成をdocker-composeで用意します。 version: "3" services: redis1: image: redis:6.2.6 ports: - "637
NEG(Network Endpoint Group)を使った負荷分散 - Carpe Diem
概要 従来のGKEのロードバランサーはNodeに到達後iptablesで再度負荷分散するという２段階ロードバランシングでした。 これによりレイテンシの増加、分散のばらつきといった問題が生じていました。 ref: Google Cloud Blog - News, Features and Announcements しかしNEG(Network Endpoint Group)という機能を使うことで直接Pod宛てに負荷分散を行うことができ、上記の問題を低減することが可能となっています。 ref: Google Cloud Blog - News, Features and Announcements 今回のそのNEGを実際に利用する方法を紹介します。 環境 GKE v1.18.12 NEGの種類 NEGは大きく３つ種類があります Zonal NEG GCE VMやGKE Podsにルーティン
gRPCのヘルスチェック - Carpe Diem
概要 gRPCサーバのヘルスチェック方法として HTTPサーバを別途立ち上げてHTTPでチェック tcpでポートがopenしたかチェック といった方法がありますが、前者はgRPCサーバなのにHTTPサーバを用意しないといけなかったり、後者はtcpのopenは実際にServe開始したタイミングではないといった課題があります。 そこでKubernetesでは３番目の手段として何かしらのヘルスチェックのgRPCをコマンドラインから呼んでチェックする方法を推奨しています。 ref: Health checking gRPC servers on Kubernetes - Kubernetes 環境 go 1.13.5 grpc-go 1.27.1 Kubernetes v1.15.5 GRPC Health Checking Protocol ３番目の手段ですが、実はgRPCの方でヘルスチェック用
様々なrate limitアルゴリズム - Carpe Diem
概要 インターネットに晒されているWebサービスでは TV等で紹介されたことによる大量流入 悪意ある人物からの攻撃 クライアントのバグに依る大量リクエスト など、本来想定していた以上のトラフィックが来ることはよくあります。 単純にシステムを構築すると大規模トラフィックに対応できずシステムがスローダウンしてしまうため、何かしらrate limitをかけておいた方が良いです。 ただしrate limitと一口に入っても色々あるため、今回は主なrate limitアルゴリズムを紹介します。 Leaky bucket Leaky bucketはデータ転送レートを一定にする（＝上限を設定する）アルゴリズムです。 下の図のように、様々な流量の水流がそのバケツに流れ込んでも小さな穴からは一定の水流が流れ出す仕組みです。 ref: What is the difference between token
goroutineはなぜ軽量なのか - Carpe Diem
概要 以前の記事で christina04.hatenablog.com Goはスレッドよりはるかに軽量なgoroutineでC10K問題を解決する、という話をしましたが、goroutineが軽量なのはなぜか？という理由を深掘りしたことがなかったのでしてみました。 環境 golang 1.11.1 Darwin 17.7.0 軽量と呼ばれる理由は２つ 大きく分けると以下の２つのポイントがあります スレッドに比べてメモリ使用量が低い スイッチングコストが低い それぞれ説明していきます。 goroutineがスレッドに比べてメモリ使用量が低いのはなぜか スタックとヒープのメモリの使い方を理解すると分かります。 ヒープはメモリの下層、プログラムコードのすぐ上にあり、上に向かって成長します。一方スタックは仮想アドレス空間の一番上にあり、徐々に下に成長していきます。 ref: イベントループなしでの
Non-Blocking I/O, I/O Multiplexing, Asynchronous I/Oの区別 - Carpe Diem
概要 各言語がC10K問題をどう解決してきたかを調べてみたところ、Non-Blocking I/O, I/O Multiplexing, Asynchronous I/Oの区別がよく分からなかったので調べてみました。 正直なところ人によってちょこちょこ定義が異なるのではっきりとした答えはなさそうですが、自分で調べてしっくりした形をまとめます。 前提 同期と非同期の違い 用語 説明 同期 OSにタスクを投げて、入出力の準備ができたら アプリケーションに処理が返ってくる 非同期 OSにタスクを投げて、入出力が完了したら通知をもらう ブロッキングとノンブロッキングの違い 用語 説明 ブロッキング OSへ依頼したタスクが完了するまで待つ ノンブロッキング OSへ依頼したタスクの完了を待たない Blocking I/O ref: java Selector is asynchronous or no
Kubernetes を使ったマルチホスト環境でのクラスタを構築する【基礎編】 - Carpe Diem
概要 Kubernetesを使ってDockerのクラスタを構築します。Kubernetesを使うことで以下のような本番環境を意識したシステムを構築できます。 フェイルオーバー（コンテナが異常終了したことを検知し再起動させる） スケーリング（起動しているコンテナの数を自由に変更できる） ロードバランス（複数のコンテナにリクエストを振り分けて負荷分散する） サービスディスカバリ（サービスへのルーティングを自動で提供する） この構築は長いので記事自体も複数に分けて進めます。 アーキテクチャ コンポーネント名 説明 apiserver kubernetesを操作するためのAPIを提供する controller-manager コンテナの状態管理やノードの管理と言った各種管理作業を行う kube-proxy コンテナへのネットワークルーティングおよび負荷分散を行う scheduler 各ノードに対し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
