初めてのパブリッククラウド

この記事は、PIXTA Advent Calendar 2017 15 日目の記事です。

はじめまして、開発部でインフラを担当しているしまだと申します。
今年の4月にピクスタに入社して8ヵ月が経ちました。
入社前は、オンプレミスやプライベートクラウドでサービスを運用しているプロジェクトのみに従事してきましたが、ピクスタで初めてパブリッククラウドでのサービス運用に携わりました。

今回は、私がピクスタに入社して初めて使用したパブリッククラウド上のサービスのうち、Amazon Elasticsearch Service（以下、AWS ES）での経験を紹介したいと思います。

AWS ES上のkibanaでプロダクション環境のログを閲覧・検索できるようにする

背景

PIXTAでは、全てのアプリケーションをはAWS上に構築しており、これらのデプロイをWebコンソール上から実施しています。
アクセス権限なども細かく設定されているため、一部のエンジニア以外はプロダクション環境のサーバに入れないようになってます。そのため、障害調査などでサーバ上のログを参照する必要があっても、初期調査は特定のエンジニアしかできない状態でした。

そこで、プロダクション環境でアプリケーションが出力するログ*1をAWS ESに入れ、kibanaで閲覧・検索できるようにしました。

検証中・導入後で発生した問題と解決策

このシステム自体は、プロダクション環境のサーバにtd-agentとfluent-plugin-aws-elasticsearch-serviceをインストールする事で簡単に構築することができます。
作業の詳細は参考になる記事が沢山あると思うので、ここでは、私がシステムを検証している最中、あるいは導入後に遭遇した事象とこれらへの対処方法をいくつか紹介します。

ログ量
検証時に全てのログレベルを対象にしてAWS ESへ送ってみると1日100GBを超える勢いでデータが溜まりました。
そこで、導入に向けてINFOレベル以下のログを除外しました。
インデックス数
ログの検索が高速になるため、当初は1時間ごとのインデックスを作成していました。
数日後、シャード数が異常な数値となりクラスタが崩壊、再起動-リストアを繰り返すようになってしまいました。環境の問題かと思いAWSのサポートに問い合わせたところ、データ量の急増によりシャード数が推奨値より2桁多くなっていることがわかりました。
そこで、保持期間は1週間とし毎日、日単位にreindexと削除を実行するようにしました。
reindexの処理時間
毎日、夜間にreindexを実施したところ、前日の半日分のデータが消えてしまうようになりました。
スクリプトでreindex後に旧インデックスを即削除していたのが原因で、手動で状況を確認しながらreindexを実行すると、処理にかなりの時間が掛っていることが分かりました。
そこで、旧インデックスの削除は翌日に実行するようにしました。
複数行のログ
導入後、たまに1行空のログが出ていることに気付きました。
ログファイルを確認すると、複数行出力されているFATALログが存在することが分かりました。
そこで、td-agentの設定で"format multiline"を指定することで対応しました。