Akihiro KuwanoExperienced server engineer, Solution Architect of cloud computing at Amazon Web Services Japan
こんにちは、藤本です。 先日、Amazon Athena のクエリ結果を SPICE にインポートして、 QuickSight で可視化するというブログをエントリしました。その時に得られた知見をもう一つご紹介します。 タイトルが何を言っているのか分かりづらいですが、、、ELB のアクセスログのタイムスタンプはフォーマット上、Athena の Timestamp にも、QuickSight の Date タイプにも適合しません。でも、グラフ表示上、Date として扱いたいです。タイムスタンプの文字列でも、Athena の場合は、timestamp like '2017-01-01T10:%'というようなクエリで、QuickSight の場合は、Start with フィルターである程度の絞り込みはできますが、柔軟なクエリをしたい場合に複雑なクエリや、細かいフィルターの指定が必要となります。何
この記事はリクルートライフスタイル Advent Calendar 2016の2日目の記事です。 はじめに 弊社ではログ収集にfluentd v0.12を主に使っており、システム自体はAWS上に構築しています。 fluentdのAggregatorには、ノードの追加がしやすいように負荷分散にELBを使う構成にしています。 ここ最近までは、複数のサービスからのログを1つのELBで受け、各Aggregatorノードで処理するという構成をとっていました。 ただログが増えてくると安定性に問題が出てきたため、その際に対策として行ったことについてまとめます。 やったこと 1. コネクション数とログ量のアンバランスを解消する fluentdのsecure-forward output pluginは、コネクションを切らずにログを送り続けます。 またELBは最もコネクション数が少ないノードへ接続を行う負荷
AWSのロードバランサであるELBではSSLの暗号化通信をクライアント<->ELB間で完結させるためのSSL Termination機能が備えられています。ELBにSSL証明書を配置することで、ELB配下のEC2にサーバ証明書が不要になりました。このメリットは、暗号化処理の負荷をWEBサーバからELBにオフロードすることができる点と、証明書の更新作業時に各サーバにサーバ証明書を配布して回る手間を軽減することが出来る点だと考えています。 とはいえ、証明書の更新時期が来たらELBに設置している証明書を更新する必要があります。通常のFQDN形式のサーバ証明書なら紐づくELBは1台だと思いますが、ワイルドカード証明書を利用している場合には更新対象のELBが数十台にもなることもあります。 この更新作業を繰り返し手動でManagement Consoleから実行するのは筋が悪いので、AWS CLIのみ
こんばんは、三井田です。 今回は、Elastic Load Balancing (ELB)とRoute 53のヘルスチェックの仕様の違いについて簡単にまとめてみたいと思います。 ELBのヘルスチェックはご存知のとおり、ロードバランサがどのバックエンドインスタンスにトラフィックをルーティングするかを判断するために用いられます。 一方、Route 53のヘルスチェックは、重み付けラウンドロビンやDNSフェールオーバーで、どのIPアドレスを回答に含めるかを判断するために用いられます。 ヘルスチェック仕様早見表 まずは、以下の表にご覧下さい。 サービス ELB Route 53 ヘルスチェック元 (Health Checker)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く