この記事は、CyberAgent Developers Advent Calendar 2019 4日目です。
はじめに
おひさしぶりです。長い記事を書くことが大好きな@prog893です。Project Baikonurという私がここしばらく進めているインフラ周りのものをOSS化する仕組みについて話したいと思います。
Project Baikonur is 何
Project Baikonurとは、弊社でTerraformのモジュールや様々なインフラ周り、開発効率を向上するツールをOSS化するプロジェクトです。元々、社内OSSプロジェクトとしてはじまり、この記事で説明する様々な経緯があってGitHubで一般公開することになりました。モジュールやツールを社外でも利用できるように出していってます。
なぜProject Baikonurを立ち上げることになったのか
とあるサービスの立ち上げのときに、ログ周りをどうしようか、という課題が出ました。当時、ECSに関する知見が現在より少なく、FargateもFirelensもありませんでした。十数パターンを設計し評価した結果、Kinesisにログを送り、そこからLambda連携でS3やElasticsearch Serviceなどに格納していく、という構成できまりました。各種Lambdaを一人で実装し、サービスがリリースされました。その構成の評判が良く、タップル誕生やREQU、CROSS MEなどのサービスに導入することになりました。それぞれのサービスの最終構成やKinesisとLambdaを使ったログ周りについてAWS DevDay Tokyo 2019での登壇資料でまとめています:
とてもうれしいことでありながら、同じコードベースを複数のプロジェクトで管理、ビルドすることになってしまいました。そしてコードベースが分かれると、一般的あるべき実装の中に、それぞれのサービス特有のニーズなどにあわせて私の手により魔改造されていきました。同じようで微妙に異なるものを私がサポートすることになりました。2つのサービスで使っていた時点でもだいぶチャレンジングだったのですが、「このまま利用サービスが増えたら控えめに言ってとてもつらいな」と危機を察知していました。
Baikonur Internal
まず最初は、Baikonur Internal（社内限定）という形ではじめました。共通的なものをみんなで作っていこう、という意味での社内OSSを目指し、例の社内VCSに共通性・一般性を意識して書き直されたモジュールをおきました。マニュアルもめちゃめちゃ書きました。これで私のサポートなしにKinesisとLambdaを活用したログ周り構成を導入することが可能になり、サービス側からの修正が入るようになりました。そしてさらに、共通化プロジェクトに対する修正のため、特定のサービスに依存するものもなかったです。
Baikonur Internalが始まって数ヶ月後、私が担当していないサービスやBaikonurチームメンバー外の同僚からもあれこれ導入したいという相談を受けることとなり、私が所属する部署内、サービス側などからモジュールの提案もありました。そして気づいたら、AWSやGCPのモジュールなど、合計30種類以上のレポジトリができていました。
Baikonur OSS
Terraform Module Registryを使いたかったこと、社内で広く使ってもらえてるものはもしかしたら社外でも役に立つかもしれない、という2つの事情があり、Baikonur OSSを立ち上げることになりました。Terraform Module Registryのページはこちらです。なぜRegistryを使いたかったかについて補足が必要ですね。Terraformのモジュールを利用するとき、モジュールのパスを指定する方法として、ローカル相対パス、Gitレポジトリ、Terraform Module Registryのパス、という三種類のものがあります。baikonur-oss/terraform-aws-iam-nofile というGitHubのレポジトリを例に、Git指定では以下のようになります：
git+ssh以外でも似たような様々な指定方法やS3、GCSを使った方式がありますが、横にとても長いですね（S3/GCS/HTTPを使ったものは、中身が確認しにくく、そもそも選択肢にありません）。そして、バージョンの指定（ピン）をしたいときは、?ref=をURIの末尾につけて、ブランチ名、タグ名、またはコミットハッシュ（ショートでも可）でモジュールのソースを指定することができます。しかし、URIが長くなりがちで、末尾での記述にあるため、バージョンの確認や変更がしにくくなっている、と私は思います。一方、同じモジュールがRegistryにあるモジュールを利用するときはこのように指定します：
こちらの方が綺麗で簡潔ですね。バージョン指定も別のパラメータになっているのでとても読みやすいです。デメリットとしては、Registryにモジュールを公開するときに満たさなければならない条件があること（例えば、semantic versioningでタグを切らなければならないこと、決まった命名規則がある、など）と、バージョン指定ではタグしか使えないことです。そのため、開発を進めているときに、一旦git+ssh方式にして、開発とリリースが終わればRegistryの書き方に戻す、という手間はかかります。
公式のオープンなRegistry以外では、Private Module Registryを使うという手もありますが高すぎましたし、PrivateなRegistryのためだけにTerraform Enterprise契約をするのもどうかなーと思い導入を見送り、公式を使うことにしました。安くなったらBaikonur InternalをRegistry化したいですね…
CLIツールについては、例えばPythonのツールは pip install aws-eden-cli だけでインストールができて、レポジトリの指定が必要なくとてもスムーズに導入できます。
現在のBaikonur OSSのレギュレーション（仮）は以下のようになっています:
- 1モジュール 1レポジトリ
- 過度なモジュール化をしない
- 例えば、Terraformリソース1つだけのモジュールを作らない
- リソースをラッピングしているだけのモジュールを作らない
- 一定のリソースタグやリソース名に命名規則を強要しない
- マニュアル、使い方などは全部英語で書き、開発も英語のみで進める
- 新しく作るモジュールやツールは、最初は社内Baikonurでつくり、熟成したらBaikonur OSSに移行する
- 社内Baikonurをインキュベータとしても使う
- ただし、弊社以外で公開する価値がないものはOSS化しない
- 例えば、社内の基盤などに依存するもの
- これらはBaikonur Internalにのみ置く
そもそも、社内で作ってきたものをOSS化しちゃっていいの？ということについては、一切問題ありませんでした。OSS化に際して、公開しようとしているレポジトリの中にまずいもの（アクセスキーや社外秘など）が入ってないかというチェックと、OSS化プロジェクトを始めるときに上長から許可を得たぐらいです。GitHub Organizationを作るために何かしら書類を書いたり、ライセンスに縛りがあるなどなく、ほぼ上長の承認だけでOKでした。ほかの弊社のOSSプロジェクトの一例として、CyberAgent Advanced Technology Studioという私が所属している部署の隣の部署が進めているcats-ossというプロジェクトや、CyberAgent公式Organizationに大量の人気リポジトリがあります。OSS化に対してオープンで積極的な文化、上司らの理解があって最高です。そしていうもまでもなく、社内BaikonurもBaikonur OSSも、就業時間内に開発しています。
有望な子、eden (ECS Dynamic Environment Manager)
ここで一つ、自慢と宣伝を一つさせてください。
弊社ではAmazon ECSを活用しているサービスが多く（私が担当しているサービスは全部ECSをつかっています）、開発環境が大量に増えがちです。この課題に対応すべく、edenという、ECSの開発環境を動的に生成してくれるAPIとCLIツールを作ってみました。「PRが作られたらECS周りを作り、クローズされると削除、ということができれば最高では？」という担当サービスからの要望を受け、作ってみました。端的にいうと、ECS Serviceやその関連のものをクローンしてくれるもので詳細はJAWS-UGコンテナ支部登壇資料を参照:
edenもProject Baikonurの一環として作っており、日に日に機能が増えて改善が進んでいます。ぜひお試しください：eden APIと eden CLI。
Baikonurのこれから
まだBaikonurにあるモジュールは少ないです。Terraformモジュールは結構、みんなが作りがちなものになるケースが多く、Baikonurにしかないユニークなものを作るのは難しい。そのため、自分の中の当分の間の方針は、Lambdaモジュールの開発です。
そして引き続き、社内Baikonurにある大量のモジュールやツールを綺麗に書き直しながら出していきます。近いうちに、ALBのログを任意のフィルタに一致するもののみ（例えば、ターゲットに到達せずエラーになったもの）をSlackにメンションつけて流すLambda、AWSのコストを日報・週報でSlackに報告するLambda、CloudWatchアラートが鳴ったらSlackに投稿するLambdaをOSS化します。もしこれらが、めっちゃほしい！というお気持ちがありましたら、Twitterなどでその旨を伝えてただければ優先度を上げて爆速リリースを目指して進めますので、ぜひ一言ください。また、こういうもの誰かが作ったらうれしいなとか、これはもっとこうやろという意見も募集しています。（GCPのモジュールもそろそろだしていかないと…）
BaikonurはTerraformに限定したプロジェクトではありません！CLIツールもあり、ベストプラクティスのドキュメンテーションもあります（社内限定）。最近話題のAWS CDKに関しても、検証と導入が進んだら、BaikonurにCDK関連のものも出していく予定です。
Baikonurチームは私を含めて3人：プロジェクトオーナー兼コアコミッタな私とプロジェクトマネージャ、もう一人のコアコミットの同僚です。最初私一人で始まって以来メンバーが増えてるとはいえ、メンバーが少なく、モジュールそのものと修正・改善の提案もっとほしいなと思っています。また、OSSプロジェクトとしてコアコミッタに弊社のメンバーしかいないのも問題視しています。宣伝活動、有志の募集などをこれからもしていく予定です。
おわりに
いかがでしょうか。サイバーエージェントのOSS化事情について語ってみました。Terraformのモジュール事情、edenという私が最優先で進めている有望なシステム、Baikonurの歴史やこれからについてまとめてみました。ぜひ感想などを聞かせてください。また、Baikonur OSSは誰でも参加できますので、一緒にやっていきたい人、メンテナやってくれる人、アイデア出してくれる人などなど、募集しております！最高なものを一緒に作っていきいましょう。
若干余談ですが、正社員として新卒入社した半期に社内でインタビューを受け、新卒インフラエンジニアが描く技術の資産化計画という記事が公開され私のドヤ顔が弊社ホームページをしばらく飾っていました。Project Baikonurはそのインタビューでの発言に対する実行です。有言実行 💪💪💪
AWS re:Inventに向かいながら飛行機でこの記事をまとめました。そのうちもしかしたらre:Invent参加レポートを投稿するかもしれないので、ご期待ください。
それでは、皆さま良いお年を！（早すぎる