トレタ開発者ブログ

飲食店向け予約/顧客台帳サービス「トレタ」、モバイルオーダー「トレタO/X」などを運営するトレタの開発メンバーによるブログです。

PoCのために限られたリソース・時間でありもののツールを組み合わせてリリースした話

*この記事は トレタ Advent Calendar 2020 の14日目 の記事です。

前回のアドベントカレンダーから早くも1年、今年も寒さとともに腰が軋むサーバーサイドエンジニア 石谷です!

今年はいろいろと激動の年でした。 トレタはというと、コロナ禍のど真ん中なプロダクトを提供するなかで自分たちに何ができるのか、東奔西走した1年だったかなぁと思います。 またプライベートはというと、Youtuberを見てFortniteにハマり、Youtuberを見てデッドバイデイライトにハマる。 (そうじゃない、もっとあるだろ。あ、今年の頭に結婚したんだった。ちなみに結婚式はコロナで延期しました 泣)

はじめに

そんな中で、僕が今年の最後に担当したのは「席指定予約」を実現するバックエンド、「汎用空き時間枠管理システム」という基盤部分になります。 「席指定予約」というのはタイトルにあるPoCプロダクトで、例えば映画館のようにご予約されるお客様が席を直に選択して予約ができるサービスです。詳しくはトレタ代表 仁さんのnoteをご覧ください。 また「汎用空き時間枠管理システム」というのは、お店にあるテーブルだったりコース料理だったり、そういったものを等しく空き時間を管理すべきリソースとして抽象化した概念で管理できるようにしようよ。という思想のもと、CTOであるハオさんを主導として立ち上がったプロジェクトです。「席指定予約」における「テーブルの確保」をこの「汎用空き時間枠管理システム」が担っています。

この「汎用空き時間枠管理システム」は単体では機能しません。現実世界のドメインをそのままモデリングする具象化レイヤーと連携する必要があり、そのドメインにおける「空き時間枠の管理」だけを担います。このように抽象化レイヤーとして「空き時間枠の管理」という責務のみを全うすることで、ドメインが変わっても同じく「空き時間枠の管理」については担当することができます。

f:id:issuy:20201209142924p:plain
テーブルをリソースとして扱うシステム

このプロジェクトについては、私がメディア連携開発チームにいた頃からの課題である「予約台帳のバックエンドが、空席にまつわる機能のエンハンス・API連携先の拡張のサイクルが鈍化している」の解決を狙ったアプローチでもあります。 プロジェクトは今年の頭ごろから議論が始まっていましたが、抽象化されているが故に社内への説明もしづらく、かつそこに集まったメンバーは他のタスクも並行していたため進みが悪い状態でした。どこか目に見えるプロダクトとして一度作ってみんなに見てもらいたいよね、という話をしつつ設計についてある程度深まったタイミングで一度凍結。

そんなプロジェクトがふたたび日の目を浴びたのが10月頃、豚組しゃぶ庵βに向けた席指定予約にこの基盤を入れられないかという話が浮上しました。 大枠の設計はできていたので、これをどのように今回の要件の中で実装するかを会話しはじめました。 だいたいこういう形で実装していけばいいよねというのが固まってきた10月半ば頃、リリース日が明らかになりました。それが12月7日。 実装期間が1ヶ月というスケジュールの中で、要件にない仕様を削ぎ落とし「技術的な検証」や「構想していたものを形にする」という部分を開発的な目標としました。 もちろんユーザー(この場合は豚組しゃぶ庵で働くみなさま、予約してご来店くださるお客様)にご迷惑をかけないことが大前提で、これをスケジュール内で担保できない場合は「席指定予約」の開発を見送るという選択肢も残されていました。

そんなこんなで慌ただしく過ぎ去った11月。前置きが長くなりましたが、今回ご紹介するのは「汎用空き時間枠管理システム」を取り巻くアーキテクチャについてです。実際は理想に対して実装できたのは2,3割というところですが、アーキテクチャとしては当初の構想を反映できたと考えているので、現時点でのアーキテクチャについて記載します。

Contentful→Hasura→Algoliaを連携させるシステム

「汎用空き時間枠管理システム」を取り巻くアーキテクチャとして、まずは関連する主要なサービスを紹介します。それがContentfulHasuraAlgoliaです。それぞれに「汎用空き時間枠管理システム」を成り立たせるための役割を持たせたので、後ほど説明します。

「Contentful→Hasura→Algoliaを連携させるシステム」と矢印を書いていますが、これは「汎用空き時間枠管理システム」におけるデータの流れを表しています。これについても後ほど説明していきますが、「汎用空き時間枠管理システム」という抽象化した概念を成り立たせるためのデータフローになります。

また今回これらのXaaSを採用したのは、限られたリソース・時間での実装、および検証という都合がありました。

Contentful、Hasura、Algoliaのそれぞれの役割

Contentful

飲食店の方に使ってもらうCMSという位置づけで、お店に存在するテーブルや営業日などの設定値を管理するのがContentfulに込めた役割です。そのため、ここは先述の具象化レイヤーにあたります。今回のプロジェクトでは「席指定予約」というドメインのための設定値を管理するレイヤーです。

Hasura

「空き時間枠の管理」というのが、Hasuraに込めた役割です。ここが「汎用空き時間枠管理システム」のコア部分になります。「席指定予約」における「テーブル」のような具象化した概念では扱わず、「リソース」という抽象化した概念で扱う抽象化レイヤーです。

「空き時間枠の管理」には大きく2つの重要な役目があって、1つは「リソース×日」でデータを表現することです。これをstockと呼びます。これは具象化すると「テーブル×営業日」にあたり、例えば「12月24日に1卓空いてる?」のような問い合わせに対して回答するためのデータです。もう1つは「stockを確保すること」で、これをstockのlockと呼びます。これは具象化すると、例えば「12月24日に1卓を確保したい」という問い合わせに応じる処理になります。また、このとき複数人が同時にstockのlockを問い合わせたとしても、確保できるのは1人だけという排他制御の仕様を守ります。

Algolia

「空き時間枠の検索」というのが、Algoliaに込めた役割です。「汎用空き時間枠管理システム」における空き時間枠の検索は全てAlgoliaが担います。Algoliaも抽象化レイヤーに分類されます。

ここでは「12月24日に1卓空いてる?」のような単純な問い合わせへの回答だけでなく、より複雑な「あらゆる検索軸への対応」を実現します。例えば「席指定予約」においてお客様は「12月24日に2名で禁煙席は空いてる?」のように問い合わせ、「汎用空き時間枠管理システム」は「その条件に合致する1卓が空いてますよ」と応答する必要があります。これが「席指定予約」ではなく「コース料理指定予約」だとどうでしょう?「12月24日に5000円〜6000円のコースは2名分空いてる?」のように検索軸が変わります。

これをHasuraのレイヤーで対応するとしたら「席指定予約」や「コース料理指定予約」またはその他のドメインで必要なあらゆる検索軸に対して素早くデータ取得するための機構(DB側でインデックス張るなど)が必要になります。つまり具象化レイヤーの要件が抽象化レイヤーである「汎用空き時間枠管理システム」に染み出します。これは「空き時間枠の管理」という責務のみを全うする上で致命的な問題になります。

このような問題を起こさないためにAlgoliaが「空き時間枠の検索」という役割を担っています。Hasuraでは具象化レイヤーにおける検索軸を「stockに対するメタデータ」として保持するだけで、特に活用しません。これらのメタデータはHasuraからAlgoliaへデータを受け渡す際に、検索軸として利用可能な項目としてデータ注入されます。ここでは「汎用空き時間枠管理システム」において基本となる「店舗、日、リソース」という概念はrequiredなものとして注入されますが、それ以外はメタデータが存在したらAlgoliaにもそのデータを持ちます。これで特別な対応なく、あらゆる検索軸に対応できるようになります。

※ただしAlgoliaで文字列を検索軸にする場合はFacetによるフィルタリングの設定が必要なので注意

Contentful→Hasura→Algoliaの連携

このような役割をもたせた各システムが「汎用空き時間枠管理システム」を成り立たせるために、それぞれがどのように連携しているか、その裏側の技術がどうなっているかを説明します。

「席指定予約」を成り立たせるための連携

まずは「空き時間枠」というデータが生成されるまでの過程です。Hasuraは抽象化した概念しか持っていないため、「席指定予約」という具象化レイヤーのドメインを抽象化した状態で受け取る必要があります。なので具象化レイヤーであるContentfulからテーブルや営業日といったデータを受け取り、stockとして扱えるようにします。次にAlgoliaですが、さきほども説明したように検索のためにHasuraからデータを受け取ります。

f:id:issuy:20201210173917p:plain
Contentful→Hasura→Algoliaの連携

これで「汎用空き時間枠管理システム」としては空き時間枠を管理するためのデータが揃いました。ですが実際に予約するお客様を忘れてはいけません。予約時の流れは以下のようになります。

f:id:issuy:20201210175040p:plain
予約時の流れ

  1. お客様は席指定予約Clientへ検索条件を入力
  2. 席指定予約ClientはAlgoliaで空き時間枠を検索
  3. 席指定予約Clientは日付とテーブルを指定して予約の作成を席指定予約BFFへ問い合わせ
  4. 席指定予約BFFはHasuraへstock(具象化すると12月24日の1卓)の確保を問い合わせ
  5. Hasuraはstockの確保に応じてAlgoliaへstockの確保を反映

このようにAlgoliaへデータが反映されれば、他のお客様が空き時間枠を検索したとしても確保済みのテーブルは表示されなくなります。また、ここでのHasura→Algoliaの処理はstockの確保状態が異なるだけで「空き時間枠」と共通のものを使用しています。

このような連携を実現するために、Contentful→Hasura→Algolia というデータフローを実装する必要があります。例えばContentful→Hasuraであれば、Contentfulで定義したデータ構造をHasuraで定義したデータ構造へ変換して置き換えるための「置き換えロジック」が必要です。しかし今回使用した各サービスだけではそういったロジックを実装することはできません。

幸い各サービスにはWebhookが実装されているため、これを利用することにしました。「置き換えロジック」をAWSのLambdaで実装し、APIGatewayが提供するエンドポイントへのリクエストでこの処理を呼び出すようにします。Webhookでは下流のシステムへデータを流すEventが発生した際にこのAPIGatewayにリクエストします。

f:id:issuy:20201214165402p:plain
Contentful→Hasura→Algoliaの間を取り持つシステム

以下ではそれぞれのWebhookについてどのような処理が呼び出されるかを紹介します。

ContentfulのWebhook

ContentfulのWebhookは、テーブルや営業日などの店舗の設定値を入力するフローの最後に「設定完了」を示すデータが更新されたタイミングでEventを発行するようにしています。

このEventを受けてLambdaで「置き換えロジック」が呼び出されるのですが、Eventによるリクエストボディに含まれるデータだけでは処理に必要なContentful側の情報が不足しています。そこでContentfulのGraphQL APIを使い、テーブルや営業日といったデータをLambda内で取得します。これをHasuraのデータ構造であるstockとして変換し、HasuraのGraphQL APIで送信します。

これでContentful→Hasuraが連携しました。

HasuraのWebhook

HasuraのWebhookでは「空き時間枠」にまつわるデータの更新を検知してEventを発行します。ここではテーブルや営業日などの設定の変更、および予約に伴うstockの確保時に漏れなくAlgoliaを更新するためにあらゆるデータ更新を検知する様にしています。ただしデメリットとして、Algolia上で同一のデータに対する無駄な更新Eventが発行される場合があります。本来であればこういった無駄のないようコントロールしたいところですが、今回は使える時間が限られているため後々の対応としました。

このEventを受けてLambdaで「置き換えロジック」が呼び出されるのですが、ここでもEventによるリクエストボディに含まれるデータだけでは処理に必要なHasura側の情報が不足しています。そこで先程も紹介したHasuraのGraphQL APIを使い、stockやそのlock状態、メタデータなどを取得します。 LambdaのロジックではHasuraから取得したデータをAlgoliaのデータ構造に変換し、AlgoliaのRestAPIで送信します。

ここでもAPIを叩くための認証が必要で、Hasuraへは先程と同様にAuth0のJWTを、AlgoliaへはAPI Keyを利用しています。

これでHasura→Algoliaが連携しました。

Hasura GraphQL APIの認証

ちなみにこれらのAPIを叩くためには、それぞれ認証を通す必要があります。Contentful, AlgoliaではAPI Keyによる認証をサポートしていて、API Keyを管理画面から取得してリクエストヘッダに付加します。ただしHasuraではMachine to Machineの通信のためにAPI Keyは提供していないようで、Auth0のJWTによる対応が必要です。そのためAuth0のMachine to Machine Tokenに対応しました。

これはHasuraのAPIを叩く際にAuth0からJWTを取得し、このJWTをリクエストヘッダに付加してHasuraのGraphQL APIを叩くという処理になります。このJWTを取得するためにAuth0のAPIを叩くのですが、ここでもやはり認証が必要です。Auth0のAPI KeyはAuth0の管理画面から取得し、リクエストヘッダに付加してAuth0のAPIを叩きます。

Contentful→Hasura→Algoliaを連携させるシステムの全体像

このようにContentful→HasuraとHasura→Algoliaのそれぞれの「置き換えロジック」を実装することで「Contentful→Hasura→Algoliaを連携させるシステム」が実現できました。この連携の流れをシステム間のリクエストのフローとして表現すると、このような形になります。

f:id:issuy:20201211190937p:plain
Contentful→Hasura→Algoliaを連携させるシステム(リクエストフロー)

まとめ

少々長くなってしまいましたが、「Contentful→Hasura→Algoliaを連携させるシステム」の話は以上です。

やってみた感想として、今回採用したサービスはどれも便利なものでした。とはいうものの「限られたリソース・時間」という制限に対してこれらのサービスがすべて解決してくれるかというと、やはり難しい。

もちろん実装期間を大幅に縮小してくれるのは間違いないです。ですがそれぞれのサービスへの習熟度が低いと、それに起因する不確実性を抱えながら進むことになります。特に期限が決まっている場合、これらの不確実性がそのまま遅延リスクになります。今回はある程度先回りしておくことでリスクを軽減できたかなと思いますが、この不確実性に起因する問題にはいくつか直面しました。そんな中で期限通りリリースできたのは、一緒に開発するメンバーに恵まれたからだと思っています。みなさんに感謝!!

また今回は技術検証の意味も込めて各サービスの検証や「汎用空き時間枠管理システム」の構築を行いました。これから開発していくプロダクトや技術的な将来像、そういったものを考える際には大きな不確実性に直面します。これに対して一歩、不確実性を解消するアクションが取れたのではないかと思います。

終わりの終わりに

トレタに少しでも興味を持っていただいた方がいれば、ぜひ遊びに来てくださいヽ(*´∀`)/
仲間も募集しています!

製品開発の失敗率を下げるために意識すべきこと

こんにちは、iOSエンジニアの高です。 みなさん、製品開発してますか?うまくいってますか?

開発しているとうまくいくこともあれば、残念ながら失敗してしまうこともあると思います。 開発自体がうまく進まないこともありますし、開発は順調なんだけれど、リリースしてみると誰も使ってくれないみたいなこともありますよね。

今日は、プロダクトマネージャの教科書であるINSPIREDから、こういった失敗をいかに防ぐか、という内容を紹介したいと思います。 個人的に本書で一番大事なんじゃないかと思えた部分です。

それは、PART Ⅰ CHAPTER6にある「製品開発が失敗する根本的原因」です。 結構序盤にあるのですが、かなり大事なことが書かれています。 これを初めて読んだ時、

うわっ、分かる!あるある!

と、首がもげるくらいうなずきながら読んでいました。

僕たちが製品を開発する目的は何でしょう。 アプリを作ること?サービスをリリースすること?
もちろんそれは大事なことです。しかし、それだけではありません。

アプリであっても、サービスであっても、それを通してユーザーの課題を解決することが本当の目的であるはずです。

ありがちな開発プロセス

ほとんどの企業で行われている開発プロセスがこちらです。

f:id:y_koh:20201209155558j:plain

上から順番に見ていきましょう。

まず、アイデアがあります。これは経営幹部、オーナー、顧客などからもたらされることが多いです。 そのアイデアをロードマップに落とすのですが、リソースは限られているので他製品との優先順位付けが必要になります。 そこでビジネスケースを作ることになります。

このビジネスケースには、

  • その製品がどのくらいの利益を上げるのか
  • 提供にどれくらいの時間と費用がかかるのか

が記されることになります。

これにより、優先順位を付けやすくなりますし、何よりステークホルダーが納得しやすくなります。優先順位が付けられると、ロードマップが作成されます。四半期とか、1年間で作られることが多いですね。

ロードマップが完成すると、次に、デザイナーやエンジニアに何を作るのかを伝えるために、要求事項をまとめます。 これはユーザーストーリーだったり、機能仕様書だったりと形は様々です。それをもとにデザイナーがデザインをし、最終的にエンジニアに要求仕様書とUI/UX仕様が届きます。

エンジニアはここからなるべく早く出荷できるように心血を注ぎます。 そして、QAチームからゴーサインが出ると晴れてリリースとなり、実際の顧客に届きます。

長々と説明してきましたが、まぁよくある開発プロセスですよね。 このプロセスですが、流れとしてはとても綺麗で何の問題もない様に見えます。 効率的に進めていこうとすると、だいたいこの流れで進めていくことが多いと思います。

あれ?ちょっと待ってください。

ではこれの何が問題だというのでしょう。

実は今説明した開発の流れは、ウォーターフォールプロセスそのものなんです。 昨今、市場の流れが早く、製品開発はLEANだのアジャイルだと素早さを求められることが常となっています。なのに、開発プロセスはウォーターフォールのままである。ということに著者は警笛を鳴らしています。

もちろん、作るものが決まっていてそれがリリースする時になっても変わらないのであればウォーターフォールは有用なことはあります。何よりプロセスとして分かりやすいです。 しかし、今日、そのようなケースはかなり稀になってきているのではないでしょうか。

この手法の10の大きな問題点

では具体的に、このプロセスの何が問題なのか、もう少し深掘ってみましょう。 問題点として、10のリストが挙げられています。 どれ一つをとっても開発チームを失敗させる理由になり得るものです。

  1. ウォーターフォールプロセスは販売主導の製品やステークホルダー主導の製品につながる。これでは、開発チームへの権限移譲が行われず、ただの傭兵になってしまう。
  2. ロードマップを考えるためのビジネスケースは実にばかげている。なぜなら、どれだけの利益を得られるかは、ソリューションの出来にすべてがかかっているから。
  3. ロードマップ主導で進めると、そこには2つの不都合な真実がある。1. 少なくとも私たちのアイデアの半分はうまくいかない。2. 可能性が証明されたアイデアでさえ、ビジネス上必要な価値を持つところまで実装を進めるには、いくつかのイテレーションが必要(タイムトゥマネー)
  4. プロダクトマネジメントの役割が要求仕様をドキュメント化することになり、プロジェクトマネジメントの1形態と変わらない
  5. プロセスの中でデザインの真の価値を取り入れるのが遅すぎる。遅すぎる参画は、ガラクタにペンキを塗る様なもの
  6. 一番タイミングを失しているのは、エンジニアの仕事を導入するのが遅すぎる点。製品開発の小さな秘密は、エンジニアはいつも最も優れたイノベーションの源であるということ
  7. アジャイル開発の投入が遅すぎる。開発段階で取り入れてもアジャイルの価値の20%ほどしか享受できない
  8. プロセス全体が非常にプロジェクト中心になっている。プロジェクト自体がアウトプット(出力)になってしまうが、本来、製品はアウトカム(成果)である。最終的には何かがリリースされるが、それは目的に合致したものではない
  9. 最大の欠点は、全てのリスクが最後に来る点。顧客実証が行われるのが遅すぎること
  10. 最後に一番大きな損失は、組織がその代わりに選択できたはずであり、選択すべきだったことの機会損失である

いかがでしょうか。 太字にしている部分は個人的に特に刺さった部分です。 本当は全て太字にしたいくらい、、本当に大切なことが書かれています。

特にアウトプット(出力)とアウトカム(成果)の話はこの中で一番意識したい部分です。

「最終的には何かがリリースされるが、それは目的に合致したものではない。」とあります。

リリースしたのに目的に合致していない?頑張って作ったのに?

これは、

  • プロジェクトをやり遂げたこと
    • これはあくまで何かをしたというアウトプット(出力)
  • 実際に顧客に必要とされている製品
    • これがアウトカム(成果)

だということです。

アウトプット自体に価値は無いんですよね。

目的がブレてしまわないために

僕が好きな開発プロセスでデザインスプリント - Wikipediaがあります。 デザインスプリントではこの様に目的のブレが起きてしまわないように、最初に、中長期目標と、何が達成されたらその目標が達成と言えるか、というスプリントクエスチョンを決めます。 これをデザインスプリントの期間中、必ず見えるところに貼り出して、常に全員でこれを見ながら進めることになります。

これは、「だからデザインスプリントが良いんだよ」という話ではなくて、それくらいしないと目的はブレてしまうということなんですね。ブレるほうが自然なんです。だからブレない仕組みを導入している、ということになります。

まとめ

僕たちは開発はもちろんですが、顧客の課題を解決できる製品を、素早く実現し、そして提供することが価値となります。
そのためには、今行っている活動を全て意味のある活動に変えていかなければなりません。
アウトプット(出力)では無くアウトカム(成果)を意識して取り組むきっかけになればと思います。

さいごに

トレタは今色んな新しいことを始めているところです。 興味がある人はぜひ遊びに来てください。

仲間も募集しております!

SREチームで導入したものをピックアップしてみるの巻

トレタ Advent Calendar 2020 の 12 日目の記事です。

こんにちは、wind-up-bird です。

2020年のアドベントカレンダー3回目の登場です。

今回は割と肩の力を抜いて書いてみます。(なので、主観とかが多分に含まれます)

ところで、トレタに入社して約2年が経ちました。

入社した当時と比べると、SREチームで使っているツールや AWS のサービスも大きく変わってきました。今回はこの2年間で導入したものや変更点などをいくつかピックアップして紹介しようと思います。(ピックアップの基準も完全に主観。)

Kubernetes の導入と集約

トレタで最初に k8s を導入したのは トレタ Now です。*1 ネイティブアプリのバックエンドとして当時は GKE 上で稼働していました。


その後、他のサービスでも k8s (EKS) の導入が始まり、このときはサービス毎に EKS クラスターを起動していました。クラスターを分割していた理由は、クラスター毎に環境が分離されており自由度が高かったこと、また問題が発生した場合は各クラスター内で影響範囲が閉じていること、というところが理由です。

しかし、これによってとても小さなサービスでもクラスターが作成されていき、乱立してしまう状態となってしまいました。これは費用対効果の面で疑問が出てきました。また、各サービスごとにクラスターのアップグレードも必要になるため、運用負荷も無視できなくなっていきました。

そこで、これは 1つのEKSクラスターにまとめて、各サービスは Namespace で分割する仕組みに変更しました。現在は、6個のサービスが EKS上で稼働しています。

f:id:w1nd-up-b1rd:20201209182605p:plain

ECS の採用

アドベントカレンダー3日目のブログでも書きましたが、トレタの顧客台帳・予約台帳サービスのバックエンドは ECS を採用しました。

tech.toreta.in

脊髄反射的に EKS 上にホストしたかった気持ちをぐっとこらえて、移行対象のサービス特性や Pros/Cons を検討した結果、最終的には ECS に決めました。

従って、現在トレタでは EKS、ECS 両方運用しています。今後も、サービスの特徴や課題によって、どちらの基盤を採用するか都度検討して行こうと思っています。

ちなみに、今はEKSもECSもどちらも同じくらい好きです。

サーバーレス

いくつかのサービスでは、 Serverless Framework を導入しています。

ウェブ版 トレタ Now
今日、これから入れる飲食店が予約できる | Toreta now

トレタCC
トレタCCにAmazonConnectを導入した話 - トレタ開発者ブログ

導入の背景は、デプロイやログの確認が容易であったり、プラグインの充実、学習コストなどの面でメリットが大きいのかなと思います。これらのサービスはフロントエンドエンジニアが主体となって継続的に開発・デプロイを行っています。

それ以外にも lambroll や AWS SAM なども目的や用途に応じて積極的に検証・導入していってます。

tech.toreta.in

AWS Organizations と SSO の導入

これに関しては、もうブログを読んで頂くのが一番早いです。

tech.toreta.in

記事の中にもある通り、以前は各AWSアカウントで IAMユーザの払い出しや、EC2へのSSH鍵の配布などの運用業務が発生していました。しかし、 現在では SSO による一元管理、SSM Sessions Manager の導入など、セキュリティや管理・運用面でも劇的に改善しています。

ちなみに、最近では WebAuthN にも対応しており、自分も Mac の Touch ID をMFAとして利用しています。

aws.amazon.com

IAM のコード管理とレビュー体制の確立

これはどちらかというと技術というより思想の話になるかもしれません。

入社当時は、Terraform は導入していたものの IAM はAWSコンソールからポチポチと設定する運用になっていました。この問題点は、強力な権限を持った IAMロール や IAMユーザ が生み出されてしまうリスクがあり、IAMのベストプラクティスからも外れてしまいます。

docs.aws.amazon.com

そこで、IAM はコード管理しつつ、レビューおよびCI/CDの仕組みを導入しました(導入してもらいました)。ツールは Miam を利用しています。

github.com

自分も予想していなかったのですが導入後の効果はとても大きくて、今ではすべてのサービスや案件において、真っ先に IAMどうするか?をチーム内で議論するようになりました。

もう少し具体的に説明すると、例えば最小権限を設定したい場合、

  • AWS のリソースは何が必要か?
  • AWSのリソース間はどのように連携するのか?
  • 作成するリソース名は何か?(言い換えると、そのリソースは何をするものか?)

etc…

というのをきちんと理解しておかないと、Action/Resource/Principal などが適切に設定できないためです。

ということで AWSの設計はIAMありき というのが今のSREチームの共通認識となっています。(多分)

最後に

ということで、4つほど紹介してみました。

ここで紹介しきれなかったものもまだまだありますが、それはまた別の機会ということで。

最後の最後に、おなじみのやつです。

corp.toreta.in

*1:正確には、内部的な利用はあったのですが、プロダクトの基盤として使われたのはこれが初めて。

© Toreta, Inc.

Powered by Hatena Blog