EmotionTechテックブログ

株式会社エモーションテックのProduct Teamのメンバーが、日々の取り組みや技術的なことを発信していくブログです。

Emotion Techインフラ業務の取組振り返り

はじめに

はじめまして、インフラエンジニアのおかざきです。 私は弊社に入社して1年半程になりますが、 入社時からの振り返りも兼ねて取り組んできたことをご紹介します。

弊社のシステム構成紹介

振り返りの前に、弊社のシステム「EmotionTech」の構成と利用技術の一部をご紹介します。

「EmotionTech 」は顧客体験や従業員体験を改善するためのソリューションを提供するクラウドサービスです。このサービスではアンケート調査を実施し、回答データを特許取得の分析技術(※1)により処理し、顧客体験・従業員体験の改善ポイントとしてインパクトの大きそうな事柄を可視化することができます。

システムはAWS上に構築されており、大きく以下の機能部があります。

  • アンケート回答画面
  • 回答の集計結果を表示するダッシュボード画面
  • 回答データのデータストア間同期やメール送信等の非同期処理を行う機能(以下、Worker)

それぞれ、フロントエンドフレームワークにAngular、バックエンドにRuby on Railsを用いています。これらをコンテナ化した上でAWS Elastic Beanstalk、ECS上で稼働させています。ここに掲載した以外にもワークフロー制御、データ分析を行う機能部がありますが、ここでは割愛します。 以下がシステム構成イメージです。

システムの使われ方を簡単にご説明します。

例えば飲食チェーン企業が店舗に来店した顧客に向けてアンケートを取得するといった案件や、自社内の従業員向けアンケートを取得するといった案件があるとします。

アンケート回答画面は、アンケートを受け取った一般の方や顧客企業の従業員の方がアクセスする形になっています。 投稿されたアンケート回答データは顧客企業がダッシュボード画面で閲覧され、顧客体験向上に活用されています。

アンケート回答データはAWS AuroraやElasticSearch Serviceに蓄積された上で、ダッシュボード画面から閲覧できます。また、特許取得の分析技術により、顧客体験の改善ポイントとしてインパクトの大きそうな事柄が可視化されます。

アンケート配信規模の増加や機能追加を俊敏に行いたいといったニーズに対応するため、最近のバックエンド、インフラ周りの取り組みとしては

  • アプリケーションのビルド・デプロイ機構をTravisCI・JenkinsからGithub Actionsに移行
  • メインデータベースのRDSをAuroraに移行
  • ElasticBeanstalk+ECSに変わる次期基盤技術としてFargateやEKSの可能性を模索

があり、徐々にシステム構成を変えていこうとしています。

インフラ業務の振り返り

次に、私自身の振り返りになります。 私は2019年7月にインフラエンジニアとして採用され、主にAWSサービスを活用したシステムの運用、トラブル対応、改善検討がミッションとなっていました。

アラート頻度を見て戦慄

この頃弊社ではお客様数の増加や特許取得の分析機能の利用が増加しており、ビジネスとしては嬉しい状態でしたが、システムではほぼ毎週緊急アラートが発生していました。 インフラエンジニアの特性(？)か入社時に真っ先にSlackのアラートチャンネルを確認しましたが、アラートの頻度を見て戦慄した覚えがあります。

例えば、以下のようなことが起きていました。

  • 平日土日問わずひっきりなしにEC2インスタンスがダウンし、エンジニアが応急処置を行ってはダウンを繰り返す…
  • デプロイを行うとインスタンスのダウンと重なって頻繁にデプロイがやり直しになる…
  • バッチ処理もリトライ機構が実装されているものの、インスタンスのダウンに引きづられて処理完了までの時間が延々と伸びる…

人手に対してとにかくトラブルの頻度が多く、どこが根本的な問題かの調査が中々進んでいない状況に見受けられました。

地道に問題を潰して時間を確保する

最初に行ったこととしては、先輩エンジニアとひたすら各サーバのリソース使用量履歴、エラーログ、過去の障害レポートを見返していきました。 インスタンスのディスク容量、Dockerコンテナのデータ領域容量、OSのOut Of Memoryログ、DBのスロークエリログ等々、基本に立ち返って手がかりを探して対策を打っていきました。

上述したような複数の事象が複数の役割のサーバで発生していたことから、 一つの事象を解消したところで中々サービス全体の安定化には繋がりませんでした。 また、油断するとインスタンスがすぐにダウンするため、最初のうちは手がかりとなるログを保全するだけでも精一杯でした。 しかし、いくつか対処を進めていくことで2019年の秋頃には緊急アラートが月1回ペース程度になり、少し余裕が出来てきました。

痛感したのは、問題が多発するとエンジニアの余裕がなくなるため、問題の真因分析や再発防止策の立案に時間を掛けることやサービス価値向上に繋がるような活動ができなくなるということです。

サービスをより良くしていくには最低限上記に時間をかける余裕が必要で、問題が山積みな場合は、地道に目の前の問題を一つ一つ解消して時間を作るしかないことを改めて実感しました。

現状改善に必要なものを考える

アラート頻度が月1回ペースにおさまってきてから、 システムで生じている他の問題や運用改善について思考できるようになりました。

この時不安として感じていたこととして、システムがどうなったらダウンするかが何もわからないことや、成長中のサービスであるので、状況が急変し、お客様のアクセスが増えるかもしれないということがありました。

そこで、以下の取り組みを行っていきました。

  • システムの実力を可視化する仕組み整備
  • システムの現状を観測する切り口の追加、観測の省力化
  • 開発の生産性向上に役立ちそうな技術の検証と実装

以下、私が主体で実装した内容を簡単に述べますが、 詳細は今後ご紹介したいと思います。

システムの実力を可視化する仕組み整備

まず、アラート頻度は下がったものの、アンケート回答者の数やデータベースの保存データ量が増加傾向にあったため、システムがどれ位のリクエスト数に耐えられるかを知りたいと考えました。 負荷試験はシステムの初期構築時に行ったと聞きましたが、それ以降はあまりできておらず手順の整理含め必要と分かったため、以下を実施しました。

  1. システムの現状を測るために負荷試験を行う環境を用意。具体的には試験ツールとしてGatlingを選定し、Gatlingインスタンスの起動、複数台で負荷発生、レポートをS3に保存して共有する流れを仕組み化
  2. DBに本番同等規模のレコードを投入するなどの手順を整理して、定期的に調査できるよう環境を整備。

上記を行うことで、「現状のデータ量でインスタンスが●台の時にアンケート回答が秒間●件来てもエラーなく受信できるだろう」というような予測を立てることができました。

加えて、弊社システムではアンケート配信数が多い日などリクエスト数が急増するタイミングがあります。突出して多かった案件のアクセス数、配信対象全体に対する回答率、インスタンスやデータベースのリソース状況等をドキュメントに記録しておくようにしました。 これにより過去の経験も踏まえて配信規模に対する必要な回答画面インスタンスの台数の予測を立てることができ、配信に対応しやすくなったと考えます。 また、顧客担当者からの「これ位配信する予定があるけどシステム落ちませんか？」といった質問にも答えやすくなり、コミュニケーションが取りやすくなったと感じています。

今後の課題として、配信に備え設備増強を行う作業はまだまだ人手に頼っている点があります。 単純にインスタンス台数を増やすとボトルネック箇所がデータベース、ElasticSearch、Workerインスタンス等に移動するかもしれない点を加味して慎重に検討しつつ、できるだけ仕組み化を進めていきたいです。

システムの現状を観測する切り口の追加、観測の省力化

ある時、顧客担当者よりダッシュボード画面に中々データが表示されないという問い合わせを受け、調査としてアクセスログを確認すると極端に処理に時間が掛かっているユーザが存在することが判明しました。

弊社システムでは性能監視のため、アプリケーションのパフォーマンスプロファイリングを行うScout APMを導入しています。 このSaaSではAPIエンドポイント毎のレスポンスタイムの中央値、95パーセンタイル値等を取得することができるため、異常な振る舞いが発生していないかといった傾向を掴むため活用しています。

上記の仕組みは導入しているものの、弊社はマルチテナント形態を取っていることもあり、 APIエンドポイント単位の統計値だけに頼ると個別のお客様で問題が発生していることに気がつきにくい状態であることが分かりました。

そこで以下の仕組みを実装しました。

  1. Athenaを用いて、S3上に格納されたアクセスログをSQLで集計できるようにしました。
  2. RedashとAthenaを連携した上で日々の集計をスケジュール実行し、特に遅い処理が発生したユーザ一覧をSlackに通知する仕組みを実装しました。

もともとは処理遅延の問題が発生した際は、ログを能動的に見に行かなければ状況が分からないという形になっていましたが、これで多少は現状把握できるようになったかと考えています。

今後の取り組みとしては、性能を含めたシステム全体的な監視項目の拡充やシステムの利用状況の可視化が必要と考えています。

開発の生産性向上に役立ちそうな技術の検証と実装

弊社のアプリケーション開発環境として各エンジニアの業務用PC、AWS上に構築した動作確認環境、ステージング環境があります。動作確認環境はコンテナ化された開発ブランチの動作確認するために利用されていますが、以下の課題がありました。

  • セット数に限りがあるため開発エンジニアの増加に伴い環境の空きが無くなり順番待ちが発生する
  • 費用低減のためSpotインスタンスを利用していることからインスタンスがダウンしていることがあり、動作確認が中断してしまう
  • 試験用のデータをAuroraからElasticSearchに同期しておく必要があるが、手作業に依存していたため同期漏れが生じることがあり、動作確認を正しく行えない場合がある

解決策としては以下の仕組みを実装しました。

  • 動作確認を行うブランチのプルリクエストが発行されたら、そのブランチに対応するコンテナ群、ロードバランサ 、DNSレコード等のリソースを自動起動する
  • リソースが起動したら、Step Functions/Lambda/Pytestを用いて各インスタンスと関連リソース、データベースの自動連携確認を行う
  • リソース起動と同時にAuroraからElasticSearchへの試験用データの同期を行う

また、上記の動作確認環境改善以外にも現在進行形で以下の取り組みを行っています。

  • サーバーサイドエンジニア(※2)に習いながらGithub Actionsのデプロイワークフローを書いてステージング環境へのデプロイを自動化
  • ECSクラスタにおけるEC2インスタンスのAMIバージョンアップやパッチ適用といった管理工数低減を狙いFargate化を模索
  • システム全体のマイクロサービス化を進めたい構想があることから、インフラをより柔軟に組めるようにEKSの可能性を模索 (現状は動作確認環境を構築し、運用負荷等を調査中。)

ちなみに、弊社で利用実績の無い技術を導入する場合ですが、長期的〜短期的にメリットがありそうか、コスト感はどうか、構築、運用、移行の難易度はどうかといった部分をある程度自分の言葉で説明できれば「やってみなよ」と言ってもらえるのは良いところだと思っています。

今後の取り組み

上述したようにシステムの安定運用のためにやりたいことはたくさんあります。インフラの設定・テスト等のオペレーションを出来るだけ自動化したり、起こりうる障害を広範に想定して信頼性を向上する仕組みを実装していきたいと考えています。

私はGoogleの提唱するSRE的な動きをして行きたいと考え、書籍「SRE - サイトリライアビリティエンジニアリング」(※3)を教科書にしながら上述の取り組みを行ってきました。

書籍に述べられていることで痛感したのは、以下の話です。

「サービスの管理タスクを受け持つチームは、コードを書かなければなりません。そうしないと、そのチームは身動きが取れなくなるでしょう。」

目指す姿はソフトウェアエンジニアリングで運用負担を軽減しつつシステムのブラッシュアップを行う事と考えます。 私はこれまでのキャリアではアプリケーションの仕様把握のためコードを読んだり、簡単なツールが欲しくなった時に少し書くという動きに留まりがちでしたが、システムのブラッシュアップを推進するためにもソフトウェアエンジニアリングの習熟も進めていきたいと考えます。

やりたいことに対しまだまだスキル不足なことを痛感してはいますが、 充実感はあるので前向きに挑戦していきたいと思います。

終わりに

弊社システム構成の簡単なご紹介と私が入社してから取り組んだことを振り返ってみました。 少しでも弊社のシステムの構成やインフラ面での取り組み内容について伝わったようでしたら幸いです。 施策として具体的に実装したものの話は今後の記事でご紹介できればと思います。

Emotion Techでは顧客体験、従業員体験の改善をサポートし、世の中の体験を変えるプロダクトを開発しています。 弊社プロダクトに興味のある方、まだまだ発展途上なところをアップデートさせるのが面白いという方、ご応募お待ちしております！

弊社の求人情報

SRE職の求人も開始しました。

補足

※1: 特許番号：特許第6588176号 弊社のブログ「Emotion Techマガジン」にも記事があります。

※2: よろしければサーバーサイドエンジニアの記事もご覧ください。

※3: SRE サイトリライアビリティエンジニアリング ――Googleの信頼性を支えるエンジニアリングチーム GoogleのWebページから英文電子版を無料で読むことができます。 https://sre.google/books/

2020年3月にセキュリティにも焦点を当てた「Building Secure and Reliable Systems」が公開されているので こちらも読んでいきたいです...!