こんにちは。メルペイ Engineering Office チームの kiko です。先月、 HashiCorp Certified: Terraform Associate がリリースされましたね。早速 @tjun さん（メルペイ SRE, Engineering Manager ）と @keke さん（メルペイ SRE ）が受験していました。というわけで、今回はこのお二人に、試験の話とメルペイの Infrastructure as Code について聞いてみました。
サマリー
- メルペイでは、クラウドのリソースや Datadogのダッシュボードなど様々なことをTerraformでコード化して管理している
- Terraform Associate Certificationは、Terraformをメルペイと同じように使っている人で英語ある程度できる人なら受かるのでは
- 今後は Infrastructure as Code で品質と生産性を高めていきたい
Infrastructure as Code とはなにか
kiko : メルペイの話を聞く前に。まずは、 Infrastructure as Code とはなんぞやというのを教えて下さい。
tjun : Infrastructure as Code とは、システムのインフラをコードで記述しようというものです。たとえば GCP（Google Cloud Platform）上のリソースはWebのコンソールからぽちぽちすると手動で作ることができるんですが、コードで管理することによって他のメンバーがレビューできるようになったり、バージョン管理できて前の構成に戻せたり、他のチームの設定を見て参考にできたり、などのメリットがあります。
keke: KubernetesでYAMLを書くのも Infrastructure as Code の一つと言えそうですね。また、マイクロサービス共通の設定みたいなことも、コード化することで適用することができます。
kiko : なるほど。コードにするメリットは分かったのですが、コード化するのって大変じゃないんですか？
keke : 何かちょっと試したいときは手動で作ることもありますが、コード化してCI/CDによる自動化がされていると手作業によるミスも防げるので、一度仕組みを作ってしまえば後は楽です。
今のメルペイにおける Infrastructure as Code
kiko : 続いて、メルペイにおける Infrastructure as Code について教えてください。いつから、何をやってるんですか？
keke : メルペイは自分が入社したときから Infrastructure as Code が行われていて、クラウドのリソースや Datadog の監視の一部など、さまざまなリソースを Terraform でコード化して、Code Review したり自動 Apply できるようにしていますね。また、モジュールとして Microservices Platformチームや SRE が共通部分を提供することによって、デベロッパーは手間が少なく、簡単にリソースを定義できる仕組みづくりをしています。これはコードの再利用性というInfrastracture as Code の恩恵の一つですね。
kiko : そういえば、前にも DatadogのDashboardをTerraformで構築する記事を書いてましたね！ところで、コード化するツールとしてなぜ Terraform を使っているのですか？
tjun : それは、自分がメルペイに（一人目のSREとして）入社したとき、既にメルカリで Terrraform を使っていたからそこに乗っかったというのと。自分自身メルペイに来る前…5年くらい前のプロジェクトで Terraform を触ったことがあって慣れていたので良いかなって思ったんですよね。（当時書いたQiita）
あと、単純に Terraform が好きというのもあります。
kiko : そうなんですね。他のツールはあまり検討しなかったのですか？
keke : 似たツールは他にもあるんですけど、 Terraform はマルチクラウドや色んなSaaSに対応しているんです。対応サービスの数が圧倒的に多く、基本的に Terraform ひとつで完結できるというのが他にない強みだと思います。利用者も多く、さまざまな Provider（Terraformが外部APIと通信するためのプラグイン）が開発・メンテナンスされています。また、プラグイン方式になっているからこそ自分でPluginを開発すればどんなリソースもTerraform管理ができる拡張性も魅力の一つです。
kiko : なるほど。 Terraform はSREの人だけが使ってるんですか？
tjun : マイクロサービス共通の仕組みの部分と、SRE独自で管理している部分がありますね。
マイクロサービス共通の仕組みづくりはメルカリの Microservices Platform チームが中心に作っていて、各マイクロサービスのリソース定義は、SREではなくバックエンドやフロントエンドの開発者が TerraformやKubernetesの YAML を書いています。ドキュメント読んだり周りのマイクロサービスのコードを参考にしながら、みんな書いていますね。
kiko : 多くのエンジニアが利用しているんですね。さきほど、マイクロサービス共通の設定、みたいな話がありましたが、具体的にはどんなことをやっているのでしょうか？
keke: マイクロサービス共通の設定は、Microservices starter kitというプロビジョニングツールによって行われてます。一つのマイクロサービスを構築するにあたって必要なGCP project, Spinnaker Application、Hashicorp Vaultの認証・認可の設定など、あらゆるリソースをプロビジョニングできるTerraform moduleです。もっと詳しく知りたい場合は、このスライドを読んでもらえると。
kiko : ありがとうございます。弊社では多くのエンジニアが Terraform を使っていろいろコード化しているということが分かりました。
試験に受かる人は…Terraform を試行錯誤して使ったことがあり、英語力もある人？
kiko : Terraform といえば、最近 HashiCorp Certified: Terraform Associate がリリースされましたね。Slack で二人が申込みをして合格するまでの流れを見てました。
kiko : そもそも、この試験を受けようと思った理由って何なんですか？
keke : スキルアップのためです。Terraform についてもっと体系的に知りたい、みたいな。試験を通して勉強したかった感じです。実は前からこの試験の β 版が公開されていて、正式版がリリースされたら受けると決めてました。
tjun : 自分は kekeさんとの 1on1 で試験のことを聞いて知って、力だめしで受けました。いま会社の Terraform ってほぼ自動化されちゃっていて、自分で試行錯誤することがあんまりないんですよね。仕組みができてるから、使うけどよく知らなかったり、あとメルペイでは使ってない機能とかもあったりする。そういうのがこの試験に出てくるから、自分の力が試せるかなと。
kiko : なるほど。実際に受けてみてどうでした？自分の知識が偏っていないか知れたり、サービスを理解できているか知るために使えそうな試験でしたか？
tjun : どうなんだろう。簡単なものもあればちょっと使ってないと難しいかなっていうのもあった気がする。
keke : メルカリ・メルペイの自動化のやり方で Terraform を使っていたら難しく感じるような問題とかもありましたね。業務だと結構使うコマンドが偏ってて…僕とtjunさんの点数が一緒だったのは、同じような環境で同じような事しかしないからだと思います。そういうのが知れたのは良かったですかね。今まで知らなかった機能を知ることによって、今後、新しいアイデアが出てくるのではないかなとも思っています。
tjun : あと自分は英語が自信ない問題があって。
keke : 分かんなかったですね、英語。
kiko : 英語って、技術的な単語とかですか？
tjun : いや、普通の単語です。英語圏の人なら当たり前に使うのかもしれない動詞とかが分かんなかったです。 試験前の、試験官からの指示もなかなか聞き取れなくて苦労しました。
kiko：この試験は技術力はもとより英語力も必要なんですね。
tjun：自分は英語そんなに苦手な方ではないんですけどね。英語力次第では最大5問くらい落とすかもしれないです。
kiko : 5問は大きいですね。他に何か苦労したことってありますか？
tjun : 完全に自分の勘違いなんですけど、試験中に公式ドキュメントを見てもいいと思ってたんですよ。公式ドキュメント見ながらなら余裕だろうと思って勉強せずに受けました。そしたら試験官から「そのページ（公式ドキュメント）は閉じて」と言われて、焦りました。ちゃんと説明読んでこいって話なんですけど。
kiko : ちゃんと試験概要を読むの、大事ですねｗ kekeさんは、事前に試験対策とかしましたか？
keke : 自分は業務経験が浅かったので、ドキュメントを3時間ぐらい読みました。全コマンド・オプションをおさえたりしてから挑みました。
kiko : えらい！kekeさんは個人ブログにこの試験についての記事をアップしてましたね。試験の流れとかも書かれてたので、もしこれからこの試験を受けるぞという人がいたら、kekeさんのこのブログも読むと良いかもしれない。
tjun : HCLとstateの仕組みを完全理解していればたぶん大丈夫！
Infrastructure as Code で、品質と生産性を高める
kiko : では最後に、今後のメルペイの Infrastructure as Code について聞いていきましょう。今後は何をやっていきたいですか？
keke: 今後は、Infrastructure as Code のガバナンス向上を図りたいと思っています。Infrastructure as Codeの理念で色んなリソースをコード化していくとそのコードが「記述的に正しいのか」という問題になってきます。間違ったコードを実行しても、自動化しているCI/CDの中でエラーとしてフィードバックされるので、特に大きな問題にはなりません。Terraformだとリソースを実際に作る前のterraform planが失敗して、事前に間違いを検知できることがほとんどです。
kiko: すでにTerraformの自動Applyなどは仕組みとして自動化されていますよね？
keke :はい。でも、そのコードが「リソースとして正当なのか」は組織のルールによって違うと思います。例えば、本番環境のKubernetesのPodは最低何個あるべきなど。
kiko: なるほど。そういうルールってどのように検知していくんですか？
keke : そのようなルール違反を検知するために、ポリシーエンジンであるOpen Policy Agent(OPA)を最近導入しました。ルールはポリシーと呼ばれていて、Regoと呼ばれるポリシー記述言語で書いています。CIの中ではconftestというCLIツールも併せて検証しています。こういったポリシーは、SREだけでなく、セキュリティやMicroservices Platformチームなど色んなチームから追加されていて、Infrastracture as Codeとマイクロサービスアーキテクチャで実現されているメルペイの品質の保守を担っています。
kiko : 既に SRE 以外のチームと一緒に取り組みを初めているんですね。
keke : はい。でも、すべてのルールがコード化が可能というわけではなくて。そのような項目をどのようにチェックしていけるのかが、今後のより良いInfrastrature as Codeの鍵の一つになっていくと思います。
kiko : さまざまなポリシーを適用して品質を守るというのは、メルペイでは特に重要そうですね…。他に今後やっていきたいことはありますか？
tjun : Kubernetesの上でマイクロサービス動かしている環境だと、大量の YAML を書いていくことになるんですが、これが正しい世界なのか？みたいな話はありますよね。もちろん最終的には YAML になるんですが、全Developerが YAMLすべて書くのではなく、もうちょっとkptやkustomizeを組み合わせたりして抽象化できないか、みたいな話を周りの人（メルカリのMicroservices Platformチームやメルペイアーキテクト）としています。
あと、マイクロサービスの監視には Datadog を利用しているんですが、Datadogのダッシュボードやモニターを各チームが都度設定しなくても共通の仕組みで自動生成できないか、みたいなことを考えて準備しています。
kiko : なるほど。マイクロサービス開発者の生産性を高めるためにも、構築や設定が簡単で便利になると良さそうですね。
おわりに
メルカリ・メルペイにおける Infrastrucre as Code の歴史は長いですが、まだ理想の状態にたどり着いていないようですね。またどこかで今後の取り組みの結果をお伝えできればと思います。
以上、SREのお二人へのインタビューでした！
