Kazuki Ono

2017 年の入社から 2018 年 8 月までサーバ監視サービスのサービス運用を担当していました。主なトピックを挙げて、運用実績を書いています。 ## インフラリソースの AWS 移行 (2017/8 月頃) - AWS でのインフラ構成 CloudFormation を YAML で定義し、クロススタックリファレンスを使ってマネージドサービスごとに CloudFormation スタックを分離して、プロビジョニングを設計実装しました。サービス要件としてインターネットからのアクセスを受けるのに IP を固定する要件があったため、 リクエストを受ける Nginx に Elastic IP を付与し、 Route 53 のヘルスチェック + DNS RR で冗長化構成を設計実装しました(現在は Elastic IP を利用できる NLB に置き換えています)。 - Active Stanby の冗長構成 AWS 移行前のオンプレミスサーバでは DB, Redis, DNS サーバの Active-Standby の構成に keepalived を利用していました。keepalived の Unicast VRRP と AWS VPC のルートテーブルを使った Active-Standby 構成を設計し、ルートテーブルをアトミックに切り替えるツールを G olang で書き、公開しました。 [GitHub - hatena/swiro: swiro - A switching route tool for AWS](https://github.com/hatena/swiro) ## 発生した主なトラブルと対処 - .io ドメインの障害 サービスで利用している mackerel.io で .io ドメインの権威サーバ障害が発生したため、 mackerelio.com を取得しました。.com ドメインを選択した理由は AWS サービスとして使われており (amazonaws.com)、 .com ドメインの権威サーバ障害が発生すると全世界的に AWS を利 用しているサービスが停止しそもそも運用できない状態となるため .com ドメインを選択しました。 - PostgreSQL 9.3 によるスピンロック 突然、 PostgreSQL の CPU が 100% になったまま戻らず、データベースにアクセスできなくなる問題が発生しました。当時はアプリケーションを全台再起動することで、回復を行いました。 調査のために PostgreSQL のソースコードを読んで調査したところ、コネクションを bind して PostgreSQL のクエリバックエンドのプロセスを立ち上げる際にスピンロックを行う処理がコードにあり、 1500 接続数を超えるとスピンロック競合が発生し、 CPU 使用率が 100% にな る問題がありました。PostgreSQL 9.4 でこの問題が解決されており、バージョンアップデートを行いました。 ## サービスパフォーマンス改善 - [メトリックのインクリメンタルサーチの速度が向上しました ほか - Mackerel ブログ #mackerelio](https://mackerel.io/ja/blog/entry/weekly/20180821) 文字列検索を行う PostgreSQL のクエリが頻繁にタイムアウトしていたため、クエリを解析しクエリオプティマイザに優先されるインデックスを作成して 1000 倍高速化しました。この際、PostgreSQL 9.3 ではクエリオプティマイザがインデックスを利用しなかったため、 PostgreS QL 9.6 にアップデートを行っています。クエリの解析には Elasticsearch に全クエリを投稿したクエリの統計処理、EXPLAIN ANALYZE (MySQL の EXPLAIN に相当) を利用しました。 また、これを受けてトランザクションによるデッドロックや遅いクエリが存在する場合、アラートを発報する仕組みを Mackerel のチェックプラグインとしてサーバに入れています。