パブリッククラウドアカウント作成自動化について

はじめに

こんにちは。IT 基盤部 19 新卒の安藤と小池です。安藤はソーシャルゲーム及びオートモーティブのインフラの運用を、小池は大規模ゲームタイトルおよびゲームプラットフォームのインフラの運用を主に担当しております。また、安藤・小池ともに全社的なパブリッククラウド利用の管理を行うチームにも参画しており、アカウント作成自動化のプロジェクトにアサインされています。今回はこのことについてお話いたします。

パブリッククラウドアカウント作成自動化

DeNA では社内で使うパブリッククラウドアカウントはすべて IT 基盤部で一元管理をしています。そのため IT 基盤部には、毎日多くのアカウント作成依頼が届きます。しかしながら現状の作成フローでは、「手作業：GUI コンソールから手入力しなければならないもの」、「半自動：API を curl コマンドで都度叩く、もしくは AWS CLI / gcloud コマンドを都度叩くもの」が多くなっています。さらに手作業・半自動が混在しているため煩雑になり、１つのアカウントを作成するために１時間ほどかかってしまうこともありました。過去には「新卒研修のために、AWS・GCP のアカウントをそれぞれ 30 ずつ準備して」という大きく工数を取られる依頼もあり、アカウント作成フローの改善が急務でした。

そこで我々は、アカウント作成業務を「全自動: 1 回のEnterだけで終了させる」ことを目標に掲げ、プロジェクトに取り掛かりました。

アカウント作成作業の現状と改善案

これらがアカウント作成効率化前後のフローです。

AWS アカウント作成

現状の作成フローでは、依頼を受け付けた後、ユーザ管理用の google group を作成し、組織用のアカウント作成権限を持つマネージャーにアカウントの作成を依頼します。

アカウント作成後は AWS コンソール上で以下の作業を行います。

ルートユーザのパスワードの変更
ルートユーザの MFA の設定
マーケティングメールの停止
IAM のパスワードポリシーとアカウントのエイリアス設定

その後は、IT 基盤部のメンバーのみが入れるサーバで以下の作業を行います。

Okta 連携用の google group の作成
新規アカウントに対して、エンタープライズサポートプランを適用
コストデータ保存用のデータセットの作成
AWS 利用ユーザの連絡先を登録

そして、アカウント管理用のスプレッドシートに情報を記入し、依頼者にアカウントを渡します。

このように手順自体が多く、作業によって実行環境が異なるため、複数の作業環境を行き来する必要がありました。

改善後は、利用可能な API や CLI を調査しそれらを実行するラッパーを作成したことで、大半の作業は１コマンドで実行できるようになりました。また、アカウント作成フロー自体の見直しも行い、作業者が複数の環境を行ったり来たりする問題も解決することが出来ました。

GCP プロジェクト作成

GCP も AWS と同様で、依頼を受けた後は入力内容を確認し、ユーザ管理用の google group を作成します。依頼を受けた作業者が GCP プロジェクトを作成した上で、課金紐付け権限を持つマネージャーに紐付け作業を依頼します。

その後は、セキュリティ自動監査用の API を有効化し、GCP を利用しているユーザの連絡先を登録し、アカウント情報をスプレッドシートに記入した上で依頼者にアカウントを受け渡します。

GCP でも、API やライブラリの整備を行い、それらをまとめて実行するラッパーを作成したことで、最初と最後の kintone の確認とスプレッドシートへの情報の記入以外は１コマンドで実行出来るようになりました。

次の節で、それぞれのトピックに対して、どのような課題を見つけ改善を行ったか詳細を説明します。

自動化・効率化の詳細

kintone

DeNA ではワークフローツールとして kintone を利用しており，パブリッククラウドアカウントの作成依頼も kintone で申請されます。

自動化への課題

基本的に依頼対応に必要な情報は全て kintone のレコード上に集まっています。しかし、現状では入力項目を kintone から出力する機能を使用していませんでした。

例えば、アカウントオーナー用の google group を作成する場合は、下記の情報をパラメータとして渡す必要があります。

作成するクラウドアカウント名
依頼者
部署の連絡先

この作業を１アカウントごとに十数回行う必要があるため、コピペミスが度々発生していました。また、IT 基盤部でクラウドアカウントを一括管理する上で必要な命名規則が定められており、入力された内容がその命名規則に則っているかどうか人の目で見て確認する必要がありました。特に GCP の場合、一度プロジェクトを作成したら、プロジェクト ID を変更できないため、最初から作業をやり直す必要があります。

改善効果

上記の課題を解決するために、 kintone API を用いて入力項目を取得し、下記ようにレコードの ID を指定するだけで、入力内容のバリデーションを行い、アカウント作成に必要な処理の実行できるようになりました。

$ create-cloud-account -r $record_id

バリデーションを行い問題があった場合は、実行画面に問題の箇所を示すエラーメッセージが表示されます。これにより、アカウントの一括管理において致命的な問題はアカウント作成前に気付くことができるようになりました。

$ create-cloud-account -r $record_id

2020-03-18T06:53:51 [ERROR] suffix does not match -(aws|gcp)
2020-03-18T06:53:51 [ERROR] dena-pca-improved-test-gcp-project

アカウント名に問題がない場合は、確認画面に進みます。

$ create-cloud-account -r $record_id

以下のアカウントを作成します
Cloud type: GCP (Google Cloud Platform)
Accounts: ['dena-pca-improved-test-gcp']
email: ['xxx@example.com']
contactGroup: yyy_my@example.com
gcpCostFlag: 4

アカウント作成を実行しますか？ y/n >>

スクリプト実行完了後は、後続作業に必要な情報を自動で kintone レコード上にポストするようにし、その後の手作業が必要なタスクをスムーズに行えるようにしました。

google group

なぜ google group が必要か？

DeNA では、パブリッククラウドアカウントのユーザ管理に、google group を利用しています。パブリッククラウドアカウントのオーナーを google group にし、その google group に各ユーザが参加するというような仕組みです。各プロジェクトのオーナーは、パブリッククラウドアカウントのオーナーではなくgoogle group のオーナーとなり、その google group のメンバーを管理する権限が与えられます。このような仕組みを取ることで、異動・退職時などのユーザ管理を各プロジェクトのオーナーが柔軟に行えるようになっています。

自動化への課題

google group を作成・管理するためには、GUI コンソールを使用する方法と G Suite Admin SDK の API を使用する方法の２通りがあります。後者を利用するための内製 API を IT 戦略部が作成してくれており、現状ではその内製 API を curl コマンドから叩くことで google group を作成・管理していました。この方法はコピペのみで実行でき、 GUI を使った場合に比べて作業効率は上がっていました。しかしながら 10 数行のコピペを繰り返す作業は、やはり単調でミスも出やすいため全自動化したいという課題がありました。

さらに、この内製 API には「google group を作成してから 300 ~ 400 秒程度経過後でないと google group の設定が変更できない」という仕様があります。これは、 google group を作成・修正するための API が Admin SDK Directory API と、 Admin SDK Groups Settings API の２種類あり、それぞれの内部処理が非同期で行われていることから、内製 API 側も google group の作成とその設定変更を同期的に行えないというものです。また rate limit の観点からも、内製 API はこの仕様とせざるを得ないとのことでした。よって、現状ではこの遅延を受け入れるほかがなく、リトライ機能を実装したいという課題もありました。

google group 作成後、リトライを繰り返し、約６分後に google group の設定を変更できたときのログ

2020-03-17T20:31:59 [INFO] Create GoogleGroup
2020-03-17T20:31:59 [INFO] type: aws, name: dena-pca-improved-test-aws
2020-03-17T20:32:01 [INFO] {'email': 'dena-pca-improved-test-aws_my@example.com', 'name': 'dena-pca-improved-test-aws'}
2020-03-17T20:32:01 [INFO] Edit whoCanJoin. Please wait patiently...
2020-03-17T20:33:44 [WARNING] {'Urllib3Error': ResponseError('too many 404 error responses')}
2020-03-17T20:33:44 [INFO] Edit whoCanJoin. Please wait patiently...
2020-03-17T20:35:28 [WARNING] {'Urllib3Error': ResponseError('too many 404 error responses')}
2020-03-17T20:35:28 [INFO] Edit whoCanJoin. Please wait patiently...
2020-03-17T20:37:12 [WARNING] {'Urllib3Error': ResponseError('too many 404 error responses')}
2020-03-17T20:37:12 [INFO] Edit whoCanJoin. Please wait patiently...
2020-03-17T20:38:07 [INFO] {'whoCanJoin': 'ALL_IN_DOMAIN_CAN_JOIN'}

実装のポイント

上記の課題、特にリトライ機能を実装するために、リトライ用のモジュールが用意されている urllib3 を使って API クライアントを作成しました。 urllib3 を使うことで、リトライまわりをすべてライブラリに任せることができたので、実装の工数を多く削減できました。

また上記の通り遅延が発生するような仕様があるなど不安定な API であるため、失敗することを前提として「何に失敗したか」をエラーコードとして表示し、「どう対応するか」を手順書にまとめました。

さらに、作業者によらず API クライアントの各機能を単独でも実行できるようにするために、 CLI ツールを整備しました。その際、 Python Fire を利用したことで、CLI ツール作成にかかる工数を、大きく削減できました。

失敗した処理がある場合に表示される kintone コメント例
- error:130 は google group へメンバーが追加できなかったことを表しています。

IT 基盤部作業者は引き続き以下の作業をお願いします。
https://example.com/wiki にある残処理
----------------------------------------
#accountName, #accountId
dena-pca-improved-test-aws, 123456789
--------------------error--------------------
target:dena-pca-improved-test-aws error:130
---------------------------------------------

google group のメンバを表示する CLI ツール実行例

$ control_google_group show-members dena-pca-improved-test-aws | jq .
{
  "members": [
    {
      "role": "MEMBER",
      "email": "hoge@example.com"
    },
    {
      "role": "OWNER",
      "email": "fuga@example.com"
    },
  ]
}

AWS アカウント

自動化への課題

DeNA では、 AWS Organizations を利用したマルチアカウント管理とセキュリティ自動監査を行っています。 (詳細は DeNA の AWS アカウント管理とセキュリティ監査自動化を参照ください) そのために初期設定する必要のある項目のうち、下記の自動化されていないものがありました。

aws organizations create-account で作成したアカウントのルートユーザの初期パスワードの設定
aws organizations create-account で作成したアカウントのルートユーザの MFA 登録
IAM パスワードポリシーの適用

また、運用上必要な設定で自動化されていない下記の項目もありました。

AWS のマーケティングメールの unsubscribe
ログイン URL のエイリアス作成

上記5項目を CLI 化し自動化できるか調査し、実際にコーディングすることが自動化への課題でした。

自動化できたもの

「IAM パスワードポリシーの適用」と「ログイン URL のエイリアス作成」は AWS CLI を用いて自動化することができました。 AWS CLI を叩くためには、作成したアカウントに switch role するために高い権限が必要なので、マネージャーに叩いてもらうスクリプトに組み込んでいます。

IAM パスワードポリシーの適用 ( AWS CLI Docs )

$ aws iam update-account-password-policy \
--minimum-password-length 8 \
--require-uppercase-characters \
--require-lowercase-characters \
--require-numbers \
--require-symbols \
--allow-users-to-change-password
$ aws iam get-account-password-policy
{
    "PasswordPolicy": {
        "MinimumPasswordLength": 8,
        "RequireSymbols": true,
        "RequireNumbers": true,
        "RequireUppercaseCharacters": true,
        "RequireLowercaseCharacters": true,
        "AllowUsersToChangePassword": true,
        "ExpirePasswords": false
    }
}

ログイン URL のエイリアス作成 ( AWS CLI Docs )

$ aws iam create-account-alias --account-alias "dena-pca-improved-test-aws"
$ aws iam list-account-aliases
{
    "AccountAliases": [
        "dena-pca-improved-test-aws"
    ]
}

自動化できなかったもの

aws organizations create-account で作成したアカウントの、「初期パスワードの設定」と「MFA 登録」は自動化できませんでした。

「初期パスワードの設定」に関しては、『組織からアカウントを作成する際 (コンソール経由、コマンド使用共に)、初期パスワードを取得したり、パスワードを指定できない』という仕様になっているようです。 AWS Documentation

この作業が自動化できると工数削減効果がとても大きいので、今後ご対応いただけることを期待しています！

自動化を見送ったもの

「AWS のマーケティングメールの unsubscribe 」は、工数の割に効果が見込めないので今回の自動化を見送りました。

「AWS のマーケティングメールの unsubscribe 」は、現状コンソールから行っています。これを CLI で行えないかと AWS に問い合わせも行いましたが、「マーケティングメールの購読解除の設定はコンソールからのみ」との回答でした。よってこれを自動化するためには、selenium などでブラウザ操作を自動化する他なく、工数がかかると判断し断念しました。来期以降に、ブラウザ操作を自動化を週次バッチ処理として動かしたいと考えています。

GCP プロジェクト

自動化への課題

GCP も AWS 同様、セキュリティの自動監査やコストの監視を行っています。 IT 基盤部側では、以下の作業を行った上で依頼者に GCP プロジェクトをお渡ししております。

１．オペレータが実行

プロジェクトの作成
IAM の設定
コスト管理用のデータセットの作成

２．マネージャーが実行

課金の紐付け

３．オペレータが実行

その他自動監査に必要な API の有効化

そのうちの 1. の作業は既に自動化出来ており、下記のコマンドを GCP コンソール上で実行するだけです。

./create-gcp.sh --project=$PJ_NAME --owner=$PJ_OWNER --group=$PJ_GROUP --flag=$PJ_ORG_FLAG -x

その後、課金の紐付けをマネージャーに依頼し、紐付け完了後に API を有効化するというフローになっていました。 API の有効化が自動化スクリプトに組み込まれていない理由としては、一部の API は課金の紐付け後でなければ有効化できない仕様となっているからです。

以上の経緯から、オペレータとマネージャーそれぞれがプロジェクト作成に必要なスクリプトを別で管理しており、うまく連携が取れていないという課題がありました。

改善効果

最終的には、マネージャーが叩いているスクリプトとオペレータが実行するスクリプトを1つにラッパーに組み込み、３つの処理をマネージャーに行ってもらう運用になりました。前節で示した、 create-gcp.sh で指定するパラメータも kintone に記入されたものを自動で代入し実行するため、人的要因のミスは発生しないようになりました。

おわりに

以上、パブリッククラウドアカウント作成自動化についてお話しました。今回の改善効果は、1 / 4 人月ほどと見積もっています。かかった工数は２人あわせて 1 人月ほどなので、４ヶ月運用すればもとが取れる計算です。

また、今回の自動化スクリプトは 2020 / 04 から運用を開始し、現在はIT基盤部内のみなさんに使っていただきながら、随時改良や機能追加を行っています。つい最近も、IT 戦略部の方々にご協力いただき、一番のボトルネックだった google group の group settings の修正を非同期化しました。この改良により、実行時間を約 1 / 5 にすることができました。

パブリッククラウドアカウントの管理方法は各々で異なるかと思いますが、本記事の内容がなにかのお役に立てられれば幸いです。

我々は IT 基盤部に配属されて約半年が経ちましたが、配属された当初はここまでコーディングをする部署だということは想像していませんでした。今回のクラウドアカウント作成の自動化に限らず、日々のシステム運用においても単にサーバの管理だけでなく、工数・コストの削減や安定化のためのツールの開発を行なっています。そういう意味で SRE に近いと思っています。「低レイヤーから強くなっていきたいが、コーディングもたくさんしたい」という方々にぴったりだと思っているので、そのような WILL がある方々は是非 DeNA の IT 基盤部に来ていただきたいと思います。自動化したい数多くのタスクと一緒にお待ちしています。