みなさん、ごきげんよう。プレイドの@tik-sonと申します。 私たちはKARTE [https://karte.io/]というリアルタイムでウェブ接客ができるサービスを提供しており、 KARTEの売りであるリアルタイム性を保てるように、日々インフラを磨きこんでいます。 このエントリーでは、そのインフラの仕組みについて一部を紹介していきます。 今回は「1年で4億UUを解析したKARTEを支える
![1年で4億UUを解析したKARTEを支えるAutoscaling 3パターン](https://cdn-ak-scissors.b.st-hatena.com/image/square/2f7a9016755d8dd44d928c6662a3836835644c0a/height=288;version=1;width=512/https%3A%2F%2Fik.imagekit.io%2Fnewt%2F61b151f921640c0018173598%2Fe8b0bee6-6c58-449e-a75f-bbac417c7e11%2Fed7668da-0605-4e8e-b4e0-6a6c7cea97d3-1.png%3Ftr%3Dw-1000%2Ch-1000%2Cc-at_max)
検証を思いついた経緯 appサーバ側のforward設定で複数の<server>タグを管理したくない td-agentのconfigに影響されず、AWSメンテナンスやインスタンス障害の対応を行いたい アプリケーションが乗るappサーバと違い、td-agentクラスタは純粋に負荷を見極めやすいため、AutoScalingに適している fluentdのコミュニティで「TCPロードバランシングはユーザ側で試して欲しい」という状況で更新が止まっていた https://groups.google.com/forum/#!topic/fluentd/3ZuG_1dPovE td-agentクラスタ環境準備 1.環境構成 今回、VPC,SecutityGroup,AMIの作成方法は割愛。 以下の環境を準備する。 2.appインスタンスのtd-agent設定 <source> type forward <
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く