sorta kinda...

主にAWS関連ですが、これに限らずいろいろ勉強したことや思ったことを書いていきます。

Elasticsearch Service にアクセスできなくなった話

最近朝が苦手です、那須です。

過去にいくつか Elasticsearch Service についての記事を書きましたが、最近書いてなかったのでまた書いてみます。

 

何が起こったのか?

運用していた Elasticsearch Service に突然アクセスできなくなりました。 でもデータは次々と Elasicsearch Service に溜まっているように見えますし、CloudWatch でも問題があるメトリクスは見当たりません。 他の Elasicsearch Service にはアクセスできますので、ネットワーク障害とかでもなさそうです。 どうやら単体障害の模様…

ちなみに、アクセスの確認には以下のコマンドを利用しました。

$ curl -v honyarara.ap-northeast-1.es.amazonaws.com
* Rebuilt URL to: honyarara.ap-northeast-1.es.amazonaws.com/
*   Trying xx.xx.xx.xx...
* TCP_NODELAY set
ここで止まる

 

さあどうしよう…

Kibana にもアクセスできませんでした。 curl でアクセスしてもタイムアウトになって応答がない状態でした。 かといってスナップショットから復旧すると直近のデータが消えてしまいます。 それは嫌だ…何か策はないものか?

データは受け取れていてそのデータを見ようとする場合だけNGです。 きっとインスタンスのちょっとした障害なのかなと思いました。 なので、EC2 と同じように再起動で復旧しないかなと思ったんですね。 でも、Elasicsearch Service はインスタンスの再起動ってアクションがありません。

 

最終的にやったこと

今回はドメイン編集でインスタンスタイプを変更してBlue/Green デプロイを発生させて、問題があると思われるインスタンスを捨てることを試みました。 インスタンスタイプが変わってステータスもアクティブになったところで Elasicsearch Service にもアクセスできるようになりました。 最後に元のインスタンスタイプに戻して再度アクセスできることを確認して完了です。 めでたしめでたし。

 

さいごに

今回はインスタンスタイプを変更しましたが、このような事象の場合には Blue/Green デプロイが発生する方法であればなんでもいいと思います。 EBS ボリュームのサイズを変更するとか。 私が知らないだけで、もっと簡単な方法もあるかもしれませんね。 Elasicsearch Service は触れば触るほどいろんな事象に遭遇するんですが、個人的には勉強になって面白いです。

S3 バケット内の不審なファイルは Barracuda CSG に隔離してもらおう

もうすぐ花粉症の季節ですね…那須です。

これまで、セキュリティ向上の記事を 2 つ書きました。

www.beex-inc.com

www.beex-inc.com

Dome9 は主にセキュリティルールの遵守をサポートしたり、SG や IAM ユーザを知らないうちに変更されることを防いだりしてくれるサービスでした。 そして Prisma Cloud は主に様々な環境の脆弱性を定期的にチェックしてくれるサービスでした。

今回は Barracuda Cloud Security Guardian (以降 CSG) を紹介します。

いつものように会社ブログに書いたので、よかったら見てください。

www.beex-inc.com