SREのここ1年の取り組みと、今後1年でやりたい事
FiNCでSREを担当しているkenjiszkです。FiNCブログに登場するのは1年ぶりのようですので、ここ1年間で取り組んで来た事、今後1年でやっていきたい事を書きたいと思います。ちなみに、去年こんなブログを書いていました。
上記ブログでは2016年1月時点で16個のサービスから構成されていると書かれていますが、2017年5月時点で30個近くまで増えています。増える理由はいくつかありますが大別すれば新機能開発か、既存機能の切り分けという事になります。そんな中でここ1年で取り組んで来た事を紹介していきたいと思います。
Docker/ECSの導入
大きな変化の一つは本格的にDockerを本番環境で導入し始めた事です。DockerのマネージメントツールとしてAWSのECSを利用しています。Dockerを利用する事の利点は今更ここで紹介するまでもないですが、新規サービスの立ち上げや既存サービスのスケーリングなどと言った面で大きな恩恵を受けています。現時点でのECSの構成はこちらの資料に簡単にまとまっています。
地獄の非同期処理障害
去年まではFiNCのアプリケーションはクローズドサービスとして運用されていましたが、今年の1月からオープン化され誰でも利用出来るようになりました。オープン化されユーザーアクセスが延びた結果、最初に影響を受けたのが非同期処理の部分でした。
具体的に言うと、それまで非同期処理用のライブラリとしてRailsのdelayed_jobを多くのアプリケーションで使用していましたが、デキュー時の動作が大規模処理、特に大量のキューが詰まれた場合にパフォーマンスが出ずに非同期処理が遅延し続けるといった問題が発生しました。
こういった状態を受け、開発チームと協力しスケール出来るライブラリの選定を行ったり、FiNCのマイクロサービス構成における正しい非同期処理のあり方などを議論しました。現在ではキューが大量に溜まった場合でもデキューパフォーマンスが劣化しないsidekiqの利用や、アプリケーション間の非同期処理をSNS/SQSを使った構成に変更するなどし増え続けるユーザーアクセスに対して安定的な運用が出来る様になっています。
ミートアップ
SRE主催で2回ミートアップを行っています。FiNCではマイクロサービス×◯◯というテーマのミートアップを行っているのですが、
Microservices×SRE
Microservices×コンテナ
というテーマでどちらも有意義なミートアップとなりました。2回目のMicroservices x コンテナに関しては、FiNC外から共同開催の依頼があり実現した物です。マイクロサービス×◯◯ で良いテーマをお持ちの方はご連絡お待ちしています！
開発環境やテスト環境に対するSREの役割
意識として大きく変わった点になります。FiNCのエンジニアチームは”ディスカスカスタマー”という仕組みを取り入れています。自分たちのチームにとってのカスタマーについて考えたり直接話したりして、本当に求められている事は何かということを再認識するための仕組みです。
SREチームが直接接しているカスタマーは開発チーム(当然その先にはアプリを使っているユーザーがいるわけですが)ですので、各チームに我々に求めている事について聞いてみました。
私の今までの認識ではSREの最優先事項は本番環境の安定/効率運用や改善といった事だったのですが、各チームと話してみると実は開発環境をもっと良くする事だったり、テストをもっと早くしたいと言った事に関しても大きく期待されている事が分かりました。
サービスが複数あると自然と開発チームが多くなるので、複数の開発環境が必要になり、しかも簡単に立ち上げたり落としたり出来る事が求められてきます(つまり1セットのマイクロサービスを複数簡単に立ち上げられる状態)。またテストの渋滞も起き始めたためテストの高速化と渋滞緩和といった要望も生じてきます。
複数の開発環境を手軽に立ち上げたいという要望はDocker/ECS化を進めていた関係で比較的すぐに出来る目処がたって来ています。環境毎に変化する項目を全て環境変数に出してしまう事で、ECSの構成定義をコピーするだけで新しい環境を作る事ができ、コンテナの立ち上げ時に渡す環境変数によって様々な環境を簡単に立ち上げられる様になっています。
テスト環境の改善に関しては、キャパシティの調整とテストの並列化といった施策をおこない高速化を試行錯誤しているところです。また環境差異を無くすため、本番環境のDocker化と同時にテストもDockerを利用して行うように変更しています。
メンバーが増えた！
去年は私1人だったSREがなんと3人になりました！まだまだ引き続きメンバーを募集しておりますのでご興味あればお気軽に遊びに来てください！
https://www.wantedly.com/projects/57858
ここからは、まだまだ足りてないけど今後取り組んでいきたい項目について書いていきます。
障害の局所化
マイクロサービスでは障害が局所化するという話を耳にするかもしれませんがそれは、そのように作った場合、だと考えています。例えば全てのサービスが同期的に繋がっているような場合では、一つのコンポーネントの障害がその他のサービスに派生してしまう事は良く起きる話だと思います。
その為、コンポーネント間を非同期通信ベースにした構成にシフトしていく、特定のコンポーネントが劣化・ダウンした場合にそのコンポーネントの影響を受けないような構成または自動で切り離すような構成にする、ステージング環境で定期的に特定のコンポーネントを落とすなどしてサービス間の疎結合性をチェックするような仕組みの導入、といった事を予定しています。
また、障害の局所化によって得られるメリットとして、障害原因の早期発見という点があります。マイクロサービスでは特に障害原因以外のところからアラートが先に上がってくる事があり、障害検知が難しいという特徴がありますが、障害を局所化しておけばこういった事が起きないため障害の早期発見・対策が可能となります。
開発環境の充実
まず、各自のローカルPCでの開発にもコンテナを導入していく事で開発環境から本番環境で一貫して同じ環境を利用出来る環境を整えたいと思っています。
統合開発環境においては、本番環境と同程度のデータサイズを持った本番模擬環境の整備をしています。本番環境のデータサイズでしか再現しないようなパフォーマンスの劣化や、再現しないバグといったものをゼロにしていく為の施策です。
最後に本番デプロイ前に、コード改修前後のAPIの性能劣化が無いかどうかを確認するような環境の準備をQAチームと一緒に進めていく計画を立てています。
セキュリティに対する役割
脆弱性診断
FiNCでは定期的にウェブ脆弱性診断を行っています。
今後も大きなリリースの際には定期的に診断をおこなっていくとともに、ツールで診断出来る部分では積極的にツールを導入し常に診断を実施しているような状況を目指しています。
アプリケーションのバージョンアップ
FiNCではRuby on Railsをはじめとして多くのオープンソースを活用しています。その為、日々バグフィックスやセキュリティパッチがリリースされており、常に最新にする事が重要と考えています。SREチームではよりバージョンアップをしやすい環境や仕組みを整えていく事が課題となっています。
可視化
可視化していきたい物はいくつかありますが代表的なところで以下が挙げられます。
パフォーマンスの可視化
Newrelicなどのツールを導入し各サービス単位での可視化はされていますが、マイクロサービス全体としてのパフォーマンス、モバイルやPCでのパフォーマンス差・電波状況の悪い環境でのパフォーマンスなどの可視化を計画しています。
ログの可視化
全てのログはfluentdで収集されs3に保管されていますが、SREチーム以外の開発チームでも簡単にログの調査などが出来る様な仕組みを整えていく必要があります。
コストの可視化
AWSの管理コンソールから全体的なコストは確認出来ますが、各サービス単位でどのくらいコストがかかっているのかと行った部分を可視化する事により効果的なコスト削減策を進めていきます。
インフラ作業を特権化しない
インフラ作業には専門的な知識やノウハウが必要な点は多々ありますが、そのすべてをSREチームだけでやる必要はないと考えていますし、それでは組織やサービスとして安定性を保ちながらスケールは出来ません。
例えば、何か一つの新しいサービスを立ち上げたいと思った時に、ECSを使用している現環境であればタスク定義をgithubで管理する事によって、開発チームがタスク定義を作成しSREチームにPull Requestを送る、内容に問題なければマージされ、その後自動で環境が立ち上がるといった仕組みを構築できます。こうしておけばサーバー環境構築も普通の開発フローと同じ様に扱う事が出来ます。
また、解決するのに専門知識が必要だった障害に関しても、それを適切にドキュメント化し同様の障害発生時にはすぐにそのドキュメントを参照出来る仕組みがあれば、誰でも対応出来る様になります。
こういった考え方の元になった背景としてマイクロサービスを運用していてサーバーの種類や開発チームの種類が増えて来た事が挙げられます。理想的には各サービスの開発チームにインフラ作業が出来る人がいれば良いのですがそれは現実的ではないので、マイクロサービスを運用する場合にはどれだけインフラ作業を開発チームに委譲出来る仕組みを整えるか、というのが鍵になると考える様になりました。
アプリケーション開発にも積極的に絡む
SREチームの責務としては、セキュリティ関連の対応やアプリケーションのパフォーマンスの向上といった部分があります。その為、そういった部分においては積極的にアプリケーションコードの修正をいっていけるようなチームを目指しています。
まとめ
今後1年でやりたい事をパラパラと書いてみました。細かい事を挙げればまだまだたくさんやりたい事がありますので、今後このブログで事例などを紹介していきたいと思っています。
