ID:82069さん

# 概要 AWS運用自動化サービスの開発・運用を3年ほど行っており、新機能開発の一例となります。 このサービスはAWSを運用される企業・人の運用コストを削減することを目的としています。 例えば「平日午後9時に特定のタグが付与されたEC2インスタンスを停止したい」という情報をサービスに登録することで、サービスからユーザーのAWS環境のAPIを呼び出してEC2インスタンスを停止する、というのがコア機能のイメージです。 チームメンバーはエンジニアが約10人、デザイナーが2人で、3ヶ月の機能開発ごとにエンジニア2-4名 + デザイナー1人でプロジェクトを進めています。 エンジニアは技術領域でポジションが分かれているわけではなく、全員が設計〜運用まで行うような形です。 # 開発概要 従来まではユーザーが自身のAWSアカウントにIAMロールを作成し、スタックが作成された後にアウトプットされた情報を私たちのサービスに1ロールごとに登録していただくフローになっていました。 しかし、AWS Organizationsでマルチアカウント構成を取られるユーザーが増えてきたため、Organizations配下のメンバーアカウントに対してIAMロールの一括作成や、まとめてIAMロールの情報を取得、ポリシーの更新をできるような機能開発を行いました。 # 行ったこと ## 設計 新機能開発では以下の3つのフレームに沿って要件を整理しています。 - Working Backwards - User Story Mapping - Example Mapping その中でも私は登録されたAWS Organizationsの情報をどのように画面に表示するかや、更新部分のExample Mappingを担当しました。 例えば - 全てのOrganizations Unitのメンバーアカウントに対して新規登録を行なったのち、特定のOrganization Unitに所属するメンバーアカウントだけに更新できるのか。その際に削除されたメンバーアカウントはどうなるのか - 新しくAWSアカウントがユーザー環境で追加された際にどうなるのか - サービス内でOrganizationsの情報を削除する際にどうなるのか といったように仕様が複雑だったのですが、できること・できないことを明確にして、どのような仕様が考えられるのかいくつか案を作成し、、チームメンバーと議論する上での叩き台を用意しました。 ## 実装 メンバーアカウントに作成されたIAMロールに付与しているIAMポリシーの更新機能を担当しました。 CloudFormationのStackをupdateするAPIを呼び出すのですが、ステータスの遷移はsidekiqを使って非同期でポーリングして確認し、更新中/更新成功/更新失敗という情報をstate machinesで管理しました。 また、フロントエンドでStackのStatusを反映するためにポーリングを行うような二重ポーリングの実装をしました。 AWSのAPIはAWS SDK for Rubyを使用しています。

# 概要 プロジェクト1で紹介したサービスの開発が主な業務ですが、このサービスのREST APIに対して特定のエンティティの情報を一括でエクスポートしたりインポートするためのCLIツールを開発しました。 ユーザーからの要望を受け、ヒアリングをしたのち、どのように実現をするのかを含めてプロジェクトをエンジニア2人で行いました。 # 行ったこと まず、チーム内で本当にCLIツールを作るべきかという議論から始めました。 REST APIは用意されているので、シェルスクリプトを用意して配布すれば良いのではないかという案も出ましたが、実行環境ごとにサポートの対応が発生する手間を鑑みて、CLIツールの作成を決定しました。 また、開発時点でGoを書いたことがなかったのでキャッチアップから始めました。 オライリーから出されている「初めてのGo言語」を読みつつ、cobraというモジュールを使用することが決まっていたので、どのようにコマンドを実行できるのかを確認しました。 また、キャッチアップもしつつ、わかりづらいところは丁寧に整理するために図解をしていたのですが、のちにブログにもしました。 https://blog.serverworks.co.jp/go-module テストも初めてのテーブル駆動のテストを書くことで、安定した動作や修正に対応しやすい状態でリリースを迎えました。