記事の目的
こんにちは、SRE船-DX(Developer eXperience)チームで内定者インターンをしていた22卒のakitoです。 昨年の11月から約5ヶ月間(週3勤務)でCI/CD周りの業務を担当したので、インターンの内容について共有したいと思います。
自分がSREでのインターンを志望した理由
自分は「特定の技術を学びたい」というよりは「その技術がどんな課題を解決できるか」を重視しています。現在、 エンジニアの転職サービスなどを見ていてもSREが多くの組織で求められており、 インフラやCI/CD周りに課題を感じている企業が多いことが分かります。実際に別の企業でインターンをした際、その課題感を直に知る機会がありました。そこで自分がSREとして活躍することができれば、より効率的にサービスを成長させることに大きく貢献できるのではないかと考えました。
freeeのDXチームの役割
freeeのSREは担当領域ごとに4つのチームに分かれており、その1つがDXチームです。DXチームでは、開発・運用で行っている作業を自動化・高速化してアプリエンジニアの開発生産性向上を目指しています!
運用している主なツールとして、CIにはGitHub Actions self-hosted runner、CDにはArgo CDが挙げられます。
最近ではArgo Rolloutsを使ったcanary releaseの導入も行いました。
developers.freee.co.jp
他にも Terraform, Kubernetes, Circle CI, GitHub Actions, ArgoCD, Datadogやその周辺の相性が良い技術を使用してます。
インターン業務の具体例
自分はCI/CD業務の経験がほとんど無かったので、多くの経験値を得るために様々なタスクを振ってもらいました。
実際に行ったタスクをいくつか紹介します。
既存のCDツールからArgoCDへの移行
ArgoCDは「Gitopsによるkubernetes向けの宣言型CDツール」です。ArgoCD Overview
簡単に概要を述べると、アプリケーションの定義/config/environmentは宣言的でバージョンコントロールできるべきです。Argo CDではApplicationのデプロイやライフサイクルを自動的で監査可能で理解しやすいようにマネージメントしてくれます。
freeeのサービスはほとんどがコンテナ化しており, インフラ基盤をAWS EKS(Kubernetes)に移行しています。
ArgoCDを使用する前に使っていた内製CDツールの課題としては
- CircleCI, GitHub Actionsなどのpublic serverでdeployするとkube-api serverをpublicにさらす事になる
- デプロイをコマンドベースで行いたくない
などがありArgoCDに移行することで改善されました。
Argo CD自体もmanifestをコード管理しており、既に開発されているmanifestを各サービスに組み込むことでArgo CD移行ができるようになっています。
私もその一環でいくつかのサービスにArgoCDの導入を行いました。
既存のCIツールからself-hosted runnerを使った仕組みの導入
freeeでは self-hosted runner をKubernetes上で管理することができる actions-runner-controller を使用しています。
簡単にGitHub self-sosted runnerとは
GitHub ActionsではGitHubが用意している仮想環境でworkflowが実行されますが、self-hosted runnerでは自分が用意した実行環境を指定することができます。
簡単にactions-runner-controllerとは
actions-runner-controllerを使うとrunnerをKubernetes上で管理することが出来るようになります。
これらを実装することで
1. Docker Imageのbuild and push をfreee管理下に置く & Docker Imageの管理コストを最小限にする
→ freeeでは以前からEKSを運用しているのでfreeeのAWSで管理することができ, 継続して運用するだけなので管理コストも低い
2. 権限管理できる統一されたContainer RegistoryにImageを置く
→ actions-runner-controllerから権限管理されているECRにImageをpush
このような課題を解決することができます。
freeeでは複数のサービスで使用しやすいようにactions-runner-controllerを使用してdocker imageをbuild and pushするworkflowを別のrepositoryに作成しており、各サービスのrepositoryからcheckoutして使用できるようにしています。
そのため私はまだ導入されていないサービスにこの仕組みを導入しました。
HorizontalRunnerAutoscaler(HRA)の導入
先ほどの説明したactions-runner-controllerにHorizontalRunnerAutoscaler(HRA)を導入しました。
簡単にHorizontalRunnerAutoscaler(HRA)とは
HRAとは、DeploymentなどにおけるHPA(HorizontalPodAutoscaler)と同様に RunnerDeploymentが管理するrunner数をメトリクスに応じて増減させる仕組みです。
これまではピークに耐え得るような数のrunnerを常に動かしていましたが、HRAの導入によって必要最小限のrunnerだけを動かせるようになり、インフラコストの削減に繋がりました。
インターンして良かったこと
- 本質的に導入する価値がある技術は導入事例が少なくても積極的に使って導入できる
- 上記のHorizontalRunnerAutoscaler(HRA)などここ2~3年くらいで使われ始めた技術をインターンでも業務として学ぶことができました。
- アプリ開発メンバーに貢献できる
- アプリエンジニアと違ってユーザーからのフィードバックなどは実感しにくいですがfreeeのアプリエンジニアの業務が楽になるためたびたび感謝の言葉を頂くことがあります。
- 失敗して攻めるのカルチャーのおかげで挑戦できた
- SREは与えられた権限によっては一つの失敗が大きなリスクになってしまいます。しかし、freeeでは限られた制約条件の中でも最大限try and error出来るような環境を用意して頂きました。また、気兼ねなくSlackやGoogle meetなどで相談出来る環境だったため心理的なハードルを感じることは特になかったです。
まとめ
SRE, CI/CDに関する知識がほとんどない中で Terraform, Kubernetes, GitHub Actions, Argo CD, Datadogなど運用方法やチーム開発の進め方などをインターンで学ぶことが出来ました。
私はインターンをする前はSREの分野はコストや情報が比較的少ないことから独学で学ぶのが難しいと感じていました。また、大規模なプロダクト群向けのCI/CDの実践的な経験を積むことは学生だと難しいと思います。SREチームでインターンをすることは同世代のエンジニアから半歩リード出来る貴重な経験になるはずです！
freeeでは新卒エンジニアを募集しています！
気になった方は是非採用ページを確認してみて下さい。新卒採用募集ページ
結論 SREインターン バンザイ!!!
