はじめに
はじめまして、freee株式会社でSRE（Site Reliability Engineering）をしている藤原峻輝と申します（各種id：@renjikari）。SREはその名が示す通りサイトの信頼性向上を目指すロールであり、freee全体のサービスの信頼性をあげるために、障害対応の運用から新しいインフラ基盤を開発することまで担当しています。
freeeについて
freeeは「スモールビジネスを、世界の主役に。」というミッションを掲げ、非効率な業務をテクノロジーで効率化し、生まれた余剰時間を創造的な事業にフォーカスすることで、スモールビジネスを強くすることに注力しています。
2013年3月、freeeはクラウド会計ソフト「会計freee」をリリースしました。サービス提供開始から5年後の2018年3月には、導入事業者数が100万を突破。現在では3600を超える金融機関や業務アプリとのデータ連携を実現し、5000を超える会計事務所と協業するほど急成長を遂げました。
freeeではビジネスの進化と同時にサービス提供の基盤であるシステムアーキテクチャも爆速で進化を遂げてきました。本記事では、アーキテクチャの進化の一例としてKubernetes基盤の進化についてとりあげてご説明します。
freeeがなぜKubernetesを使っているのか
freeeでは事業の拡大とともに開発組織も大きくなり、開発効率を向上させるため、マイクロサービス化が少しずつ推し進められてきました。そのため、言語やフレームワークが多様化し、サービスごとに少しずつインフラやデプロイフローが異なるという状況でした。
しかしこの状態では、ドキュメントや振り返りなしでの場当たり的対応によるキャッチアップコストが増大し、技術や環境の属人化といった課題が発生します。また、マイクロサービス化が進み、開発者が増えるに伴いSREへの問い合わせが増え、SREがボトルネックになることが増えてきました。
そこで、マイクロサービスをKubernetes上で運用することで依存関係をコンテナに閉じ込め、デプロイ方法をManifestとしてコード化することにしました。また、開発者にManifest作成やクラスタの作成などの運用の一部を権限移譲することで、開発者自身がインフラに手を入れられるようになり、SREのボトルネックを解消して開発の流れを滞らせないことを目指しました。
freeeのKubernetesを使ったシステムアーキテクチャの変遷
ここで、爆速で進化し続けるfreeeのKubernetesがどのように導入されてきたかを時系列で追ってみます。
- 2018年3月：Kubernetes on Amazon EC2導入
- 2019年3月：Amazon EKS導入
- 2019年10月：アプリデプロイのためのツールの抽象化レイヤーが多く難しいという意見が多かったため、シンプルな構成でデプロイできるように変更
- 2019年11月：envoyを利用し、カナリアリリース（サービスの新機能を検証確認しながら、段階的に展開するデプロイ手法）により順次検証、導入中
- 2020年1月：さらに取り組んでいる残課題
2018年3月、はじめてKubernetesのサービスを本番環境で運用開始。その頃はまだAmazon EKSが東京リージョンで提供されておらず、オープンソースのツールであるkube-awsを利用したKubernetes on Amazon EC2の構成でした。そののち、監視やログの収集機能を追加するため、アーキテクチャを少しずつ改善していきました。
具体的には監視やログ収集に関してはElasticStack（Metricbeat＋Filebeat＋ElasticSearch）を利用していました。その後、Amazon EKSが2018年12月に東京リージョンで利用できるようになったため、2019年3月にAmazon EKSを導入。同時にKubernetesへのアプリデプロイをhelm＋helmfile＋AWS Codedeploy＋Kodedeploy（Kuberenetes上でAWS Codedeployをより簡単に利用できるようにするOSSツール）に統一しました。
2019年8月にはElasticStackの監視/ログ基盤ををDatadogに移行。さらに2019年10月には、上記（3）の通り、開発者がアプリのデプロイをより簡易的に行えるよう、AWS Codedeploy＋Kodedeployを利用していた部分をCircleCIからデプロイする構成に変更しました。よりセキュアなCDのためにAWS Codedeployを利用していたものの、2つの抽象化レイヤーがあることによりデプロイが非常に複雑になっていたため、それらを減らすための改善です。
現在も抱えている課題として、CircleCIからデプロイをかけるために、CircleCIに非常に強い権限を与えなければならない点が挙げられます。本来ははできるだけ権限をKubernetes Cluster内に閉じておくべきなので、複雑性を上げることなくよりセキュアにデプロイする方法を現在も検証しているところです。
またさらなる基盤整備として、アプリのデプロイ時に簡単にカナリアリリースが利用できるような機能を導入すべく検証を進めています。
