FiNC Technologiesのサービスを支える基盤技術の紹介

こんにちは、エンジニアの鈴木(@kenjiszk)です。FiNCでは主にボルダリングをやっています。
やっぱりシステムの堅牢性を担保するには握力が大事だと考えています。今回はFiNC Technologiesのサービス基盤をどうやって握力で支えているのかを徹底解説して行きたいと思います。

FiNCアプリのアーキテクチャについて

先日の篠塚(@shinofumijp)の記事で紹介されていたようにFiNCアプリはマイクロサービスで構成されています。

このように現在までの間に徐々に大きくなって行ったマイクロサービスを支えるために、様々な基盤が整備されてきました。今回はそういった基盤についての紹介と現状の課題とチャレンジについて紹介します。

コンテナ基盤

まず最初に取り組んだ基盤改善はサーバーのコンテナ化です。FiNC TechnologiesではAWSを利用していますが、当初はEC2をAnsibleでプロビジョニングして管理していました。コンテナ化を検討するきっかけになったのは、2017年初頭に計画されていた大規模なプロモーションと、アプリケーションの本格的なマイクロサービス化です。
そのため2016年の中旬から徐々にコンテナ技術のキャッチアップと技術選定を始め、大規模なプロモーションに間に合わせるかたちで本番環境のコンテナ化を行いました。AWSのECSを利用した基盤となっていますが、詳細は2018年に開催されたAWS Summitでの登壇資料に記載しています。
ECSに移行した結果として、

• アプリケーション全体としてのスケール性能の向上
• EC2での運用に比べて余剰リソースを集約したことによるコスト削減
• Dockerfileで構成管理することにより、開発者でも環境の管理が可能となる

と言った効果が得られました。
特に、マイクロサービスの増加により環境構築コストや改修コストが劇的に増え運用担当の負荷が上がっていくことが予想されていた中で、構成管理を徐々に開発チームでも修正可能な状態にできたことがのちに続くDevOpsの推進の先駆けとなったと考えています。

CI/CD基盤

コンテナ化の次に取り組んだのがCI/CDプロセスの改善です。ここはかなり紆余曲折あり色々なアンチパターンを踏みつつ今の構成へとつながっています。現在は、CircleCIによりCI/CDを行なっています。
色々とアンチパターンを踏んだ結果、FiNCとして大切にしている考え方は以下のようなものになります。

神コマンドを作らない

過去に踏んでしまったアンチパターンの一つが神コマンドを作ってしまったことです。当時はJenkinsによりビルドを回していましたが、全てのアプリケーションがそのコマンドを実行することでビルドを行えるようになっていました。そのため、アプリケーションの数が少ないうちは良かったのですが種類が多くなるにつれて神コマンドがブラックボックス化していき、SREチームだけがエラーを治せるといった状況になりました。この反省を生かし、今はできるだけコマンドの羅列にすることにして誰でもビルドステップを理解し修正できるような環境になっています。

進捗状況とログをできるだけ見やすく

これも神コマンドによる弊害ですが、ビルドのどのステップまで進んでいてどこでエラーになったのか、またどんなエラーが出たのか、をできるだけ見やすくなるようにすることが重要です。

手間よりお金をかける

ビルドを早くする努力は大切で色々なチューニングをすることができますが、お金をかけて大きな効果が得られるのであればまずはお金をかけるという選択をすることも大事です。CI/CDはとても重要ですが、サービス提供会社として大切なのはエンジニアがサービスの向上とユーザーの満足度を上げる事になるべく工数をさく事なので、手間よりお金をかけるという考え方はCI/CDにおいては大切になります。

分析基盤

分析基盤に関してもマイクロサービス特有の課題があり、それに対応した基盤を構築しています。
これは2018年のデータ分析基盤についての資料になります。

マイクロサービスによって複雑になるのは、データやログがサービスごとに分散している為、一人のユーザーの行動ログを追おうとした時にあらゆるサービスからデータをアグリゲーションしてこないといけないという点です。
その為、Amazon DMSを利用したデータのredshiftへの集約や、fluentdによるユーザー行動の収集、集まったデータを分析しやすいサマリーテーブル(複数のアプリから得られる情報を一つのテーブルにまとめたもの)と呼ばれるものに変換するといった処理を行っています。
現在、さらに安定した運用を目指す為に分析基盤を刷新しているので完成したらまたどこかでシェアしようと思います。

監視基盤

システムの監視には古くはZabbixを利用していましたが今は一部を残してDatadogとNewrelicを併用しています。Datadogでは主にECSなどのインフラ周りの監視を行っていて、Newrelicではアプリケーションのパフォーマンスの監視を担当しています。特にNewrelicではアプリケーションのプロセスのキャパシティが取れる為、これを元にECSのオートスケーリングシステムを構築しています。
このオートスケーリングが導入された事により、より精度高く、かつすばやいトラフィックへの対応が可能となりFiNCアプリケーション基盤の安定性がぐっと向上しました。

今後のチャレンジ

現在でもいくつかのチャレンジを行なっているのでそれについても紹介したいと思います。

Service MeshとKubernetes(EKS)

一つ目のチャレンジがService Meshです。マイクロサービスが大きくなるにつれて発生した問題として、各サービスの依存関係の強まりと不明瞭さ、サービスの依存によるシステム全体の不安定さの誘発、が挙げられます。
例えば、あるサービスがアラートを検知した時に実はその原因が、依存する別のサービスにあったと言ったことはサービス全体を正常に監視できていないと原因特定までの時間が非常に長くなってしまいます。また、特に意識せずにマイクロサービス同士を結合させていくと特定のサービスが停止してしまった時に、FiNCアプリ全体が停止してしまうという状況に陥ってしまうことがあり得ます。
これを解決する策としてService Meshの導入を考えています。Service Meshによりアプリ間の依存関係の明確化や流量制限やサーキットブレイクといった仕組みを導入する事によるシステム全体の安定性の向上を目指しています。
また、IstioといったService Mesh周りのソフトウェアとの相性を考えた結果、ECSベースであったシステムをKubernetes(EKS)ベースに組み換えようと考えています。

DevSecOps

開発者と運用者がシームレスに協力して開発できるようなDevOpsの考え方をベースにこれまで基盤作りをしてきました。例えば、コンテナ化に伴いDockerfileの管理を各サービスに移譲したり、なるべく見やすいログ環境を構築することを目指しています。
最近はさらにそこにSecurityも組み合わせたDevSecOpsという考え方を取り入れようとしています。特にFiNC Technologiesはヘルスケアの領域でサービスを展開していますので、セキュリティは非常に重要なテーマです。開発者がコードを書く時点でいかにセキュリティについて考えられるか、運用者がいかにセキュアな環境を楽に維持できるかといったことが重要です。また、セキュリティエンジニアも盲目的にセキュリティ対策を叫ぶのではなく実際の開発や運用まで入った施策を行えるような組織を目指しています。

We are hiring!

本記事を見ていただいてFiNC Technologiesに興味を持っていただいた方！今後のチャレンジにあるような取り組みをしてみたい方はお気軽に遊びにきてください！ぜひここでは書ききれなかった事も含めてお話ししましょう！