【AWS】ALBから自身(EC2)を切り離したり登録するbashスクリプト - YOMON8.NET
ALBはELBと異なり複雑な構成も取れるので、必要に応じて修正して使う前提で、LBとTargetGroupとListenerが1:1:1の基本構成で作りました。 EC2をALBから切り離し ほとんどをAPIから取得する構成にしましたが、複雑な構成なら変数として持った方が良いと思われます。 また、drainingのステータスはかなり長いので本当にそれを終わるまで待つかは以下などを読んで要判断かと。 登録解除するターゲットの初期状態は draining です。登録解除の遅延が経過すると、登録解除プロセスは完了し、ターゲットの状態は unused になります。ターゲットが Auto Scaling グループの一部である場合、ターゲットを終了して置き換えることができます。ただし、ロードバランサノードと登録解除するターゲットとの間の接続は、処理中のリクエストがある場合は最大 1 時間保持されます。
Amazon Elasticsearch Serviceの検索でSQLが使えるようになったので使ってみました - YOMON8.NET
開発しているサービスの一部でElasticearch使っているのですが、ElasticsearchのクエリDSLって少し触ってないだけで忘れてしまいます。 昨日もGroupByに当たる、Aggregationを複数フィールドでやるのどうやるんだっけと、素人みたいなことで悩んでググっていました。 こういうの調べるたびに、SQL打てたらなーと思っていました。実はSQLでElasticsearchのクエリを実行する機能は、(※) Elastic Stackの有償オプションにはあります。 ※この部分認識間違いありまして、以下のコメントいただいたので引用をもって、訂正させていただきます。ありがとうございました。 Elasticが提供してるElasticsearch SQLの実行エンジン部分は無償の範囲であるベーシックに含まれてます。 https://www.elastic.co/jp/subscri
CentOS7でSystemdがメモリリークしていて使用率がジワジワと上昇していた - YOMON8.NET
ほとんどサービス動いてないサーバが急にメモリ使用率の警告出したので調べて見たら、1日に30MBくらい、1ヵ月で1GBくらいジワジワとSystemdがメモリリークしていたという話です。 事象 Systemdが異常にメモリを使っている。 $ ps aux | head USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.2 60.9 2327496 2207392 ? Ss 1月15 191:31 /usr/lib/systemd/systemd --switched-root --system --deserialize 21 root 2 0.0 0.0 0 0 ? S 1月15 0:00 [kthreadd] ... 何も動いていないのに2GBも何に使っているの？となった。 原因 結論から言うと、こちらのバグが原
CassandraでOSが不安定になったので調査したらLinuxメモリ管理設定が原因だった - YOMON8.NET
事象 環境 S/W H/W 原因 対策 Direct Reclaimを避ける 設定方法 結果 その他のチューニング項目 対策② HugePage 対策③ THP無効化 結果②・③ 参考にした情報 カーネルソースコード SlideShare WEB Page 書籍 事象 Casssandra起動してから、ある一定期間経つと突然nodetoolがとても遅くなり、ring情報見るだけでも10秒ほどかかる場合も出ていました。CassandraだけでなくOS全体が不安定になり、SSH経由の操作すらも遅くなる事象が発生しました。 Nagiosで監視をしているのですが、nrpe自体や個別のコマンドが遅くなるのでTimeOutのアラートがいくつも飛んできて何度も夜中に起こされました。 CPUやメモリ、Diskもぱっと見た数字上では余裕があり、処理自体も遅くなっていない状態。Cassandraを再起動すると
Linuxページキャッシュの設定を変更してWrite I/Oをチューニングしたメモ - YOMON8.NET
環境 設定パラメータ 計測ツール 1 ダーティーページ状況の計測ツール 出力項目 出力フォーマットと出力例 2 時間付きvmstat 3 fio(I/O負荷発生ツール) 観測 実験 チューニング例 デフォルト値 ダーティーページの最小化 キャッシュ有効活用メモリ上に乗せたまま高速処理 局所的なI/O負荷を受け流したい 参考URL 環境 以下のCentOS7環境で検証しています。 $ uname -r 3.10.0-327.13.1.el7.x86_64 設定パラメータ Linuxのページキャッシュの書き出しを設定する主なパラメータは以下です。 バッファをバイパスするI/O(O_DIRECTなど)例外を除いて、通常の書き出し処理は一旦ダーティーページに書かれて後から遅延書き込みされます。 $ sysctl -a | grep dirty vm.dirty_background_bytes =
AWS ALB配下のノードが全てUnhealtyになった場合、リクエストが全ターゲットにルーティングされます - YOMON8.NET
開発環境のALB配下唯一のEC2インスタンスがUnhealtyなのに、普通にアクセスできるので調べてみたらこんな挙動だということが。全く知りませんでした。sorry pageとか最低限のリカバリにはつなげやすいのかな。 ただ、監視をゆるめている開発や検証環境だと全てのEC2インスタンスがUnhealtyのまま、気付かずに作業しているなんてことにもなりかねないので知っておくと良いかもしれません。 正常なターゲットが含まれているアベイラビリティーゾーンがない場合、ロードバランサーノードはすべてのターゲットにリクエストをルーティングします。 ターゲットグループのヘルスチェック - Elastic Load Balancing
Apacheリバースプロキシにおけるスラッシュと%2F問題はまったポイント - YOMON8.NET
Apacheと%2Fでを調べると沢山出てくる内容なのですが、ApacheはURLから取得されるPATH_INFO変数に / のエンコードである %2F があると404を返します。 これ自体はAllowEncodedSlashesというパラメータをOnにしてやると処理できるようになります。 <VirtalHost> ... AllowEncodedSlashes on ... </VirtalHost> AllowEncodedSlashes off %2F は404エラー AllowEncodedSlashes on %2F は / にデコード これですが、デコードしないで後ろのWEBサーバに渡して欲しいという要件に合う選択肢がありません。これが一つのハマりポイントでした。 今書いている時点では日本語のマニュアルにはこの二つのオプションまでしか書かれていないのですが、英語にマニュアル見ると
AWS ELBの504ステータスのGateway Timeoutと格闘した話(最終的にALBで直った） - YOMON8.NET
ELBのメトリクスのステータスには、バックエンドのEC2が返したステータス(HTTPCode_Backend_XXX)と、ELB自身のステータス(HTTPCode_ELB_5XX)があります。 ELB自身のステータスコードの中には504というエラーコードがあります。この504エラーと格闘した話を書きます。 この504エラーは、CloudWatchのメトリクスで言うとHTTPCode_ELB_5XXに上がってきます。 このメトリクスは5XXという名前の通り、504以外のコードも含んでいます。 例えば、 HTTP 502: Bad Gateway (バックエンドサーバからのレスポンスがHTTPレスポンスとして解釈不能)や、 HTTP 503: Service Unavailable (突発的なアクセス増によりスケールが間に合わない時など） などがあります。 実際に504かどうかはS3に保存され
【AWS】ALBからCLIでEC2切り離しderegister-targetsはGracefulじゃない? - YOMON8.NET
ALBからEC2を切り離す時に使う aws elbv2 deregister-targets のコマンド、大量のアクセスがあってもエラーを返すことなく切り離すことができると思っていました。 ① EC2をALBより切り離し aws elbv2 deregister-targets --target-group-arn target_group_arn --targets Id=i-xxxxxx,Port=80 ②ステータス確認 healthy -> draining -> unused と状態が遷移するのを待つ。 ③ EC2をALBに登録 aws elbv2 describe-target-health --target-group-arn target_group_arn --targets Id=i-xxxxxx,Port=80 何度もテストしましたが①の部分で 502 ステータスが返っ
コマンドラインでEC2のコンソール画面テキスト（システムログ）を取得してgrep分析 - YOMON8.NET
EC2が原因不明で接続不可になることは以外に多いです。そんな時にVMWareやHyper-V、KVMみたいにコンソール画面に何が出ているのか確認したくなります。 AWSマネジメントコンソールから「インスタンスの設定」＞「システムログの取得」で以下のような画面が取得できるのですが、grepとかに流して調査するにはコピペしたりが必要で正直面倒です。 そんな時にはAWS CLIの aws ec2 get-console-output が便利です。ただ、このコマンドそのまま実行するとアウトプットに改行やらエスケープシーケンスやらが入って見難いです。 そこで、ポイントは --query 'Output' --output text のオプションを入れることです、これで実際のコンソール画面と同じような色つきで整形されたアウトプットが得られます。 $ aws ec2 get-console-output
AWS ALBに長いリクエストURLでGETすると414や500でエラーになる - YOMON8.NET
AWS ALB(Application Load Balancer)に長いURLリクエスト投げてみたら、以下のテーブルのように、ある長さのリクエストからエラーが出ることを発見しました。 URLの長さ(Byte) HTTPレスポンスコード 〜16446 200 OK 16447 500 Internal Server Error 16448〜 414 Request-URI Too Large AWSのサポートに聞いたら以下のような制限があることを教えてもらいました。仕様なのでパラメータ等での変更はできないようです。また、旧ELB(Classic Load Balancer)にはこの制限が無いようです。 HTTP headers for Application Load Balancers have the following size limits: Request line: 16K S
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
