シンジです。タイトルは釣りですが、実際に業務停止まで来たので、死んだには死んだのですが、まぁおそらく普通に使っていればこんなことにはならないと思うので、思い出として書くことにします。
前提として
問題の発端はGoogle G suiteのGmailについてです。
弊社はメールサーバにGmailを使っています。まぁまぁ、そういう会社さんはそこそこいらっしゃる気はします。ウチも同じように普通にGmailを普段から活用しています。便利ですよね。
でだ。
弊社、AWSアカウントを大量に保有しています。おそらく、読者の中にも「いやいや、ウチも結構なAWSアカウント数あるぞ？」と思うかもしれませんが、その5倍以上はあるはずです。アホほどあります。
AWSアカウントを発行するためには、メールアドレスが必要です。その為cloudpackでは、Gmailのグループ機能を使って、AWSアカウント発行専用のメールアドレスを払い出してやります。当然ですが、このグループの数も尋常じゃないわけです。
グループでメールアドレスを発行したところで、受信者を追加してやらないと、誰もメールを受信できません。AWSアカウント発行時に登録したメールアドレスには、かなり重要な内容のメールがちょいちょいAWSから飛んできます。なので、社内の人間は誰もが見られる状態にしておいたほうが、そのAWSアカウントで事故が起きたときなどに対処しやすくなるため、特定のユーザーのみを追加するということはしません。「ドメインの全員を追加する」というボタンをポチーと押すわけです。
こうすることによって、社内で入社・退社があっても、そのユーザーアカウントに紐付いた状態での管理状態になるため、グループに受信したメールの飛ばし先を、いちいち調整する必要がなくなるわけです。個別でメールアドレスを追加してたら事実上管理不可能になります。
まぁこうして昔から運用されていた背景があります。
何が起きたのか
Backofficeチームが、普段通り新規にAWSアカウントを発行するために、Gmailグループを追加して「ドメインの全員を追加する」というボタンをポチーと押すわけです。そうすると、
「エラー。しばらく経ってから再度お試し下さい」
Backofficeは、こう思います。
「しばらく待とう！ごはん食べてこよ〜」お昼過ぎの話しですね。
で、お昼食べ終わってオフィスに戻ってきます。
ボタンポチー
「エラー。しばらく経ってから再度お試し下さい」
ボタンポチー
「エラー。しばらく経ってから再度お試し下さい」
ボタンポチー
「エラー。しばらく経ってから再度お試し下さい」
珍しくオフィスにいたシンジ
女子「シンジさ〜〜ん、なんか〜グーグルが〜エラーって言われるんです〜」
シンジ「あーグーグルがねーグールグルつってねー」
シンジ「エラーだけにねーえらーこっちゃーつってねー」
女子「見てもらってもいいですか？」
シンジ「あ、はい、すみませんでした」
症状再現確認
シンジの手元でも同じ作業を行って、全く同じエラーが出ることを確認しました。
速攻でGoogleサポートに問い合わせます。
Google「どしたんすかー」
シンジ「なんかエラーとか言われますーこれであれでこうするとこうですー」
Google「ほっほー調べますねー」
数分後
Google「わかりましたー、制限にひっかかってますねーほっとけば直りますよー」
シンジ「あ、はーい、さようならー」
G Suiteの制限
Googleに限らずSaaSの多くは全ての動作に制限値、上限値があります。AWSであれば、上限緩和申請という裏技的なアレがあるのですが、G Suiteにはありません。分かりやすい例だと、1日に受信できるメールの数は、無制限ではないということですね。例えばこれです。
グループのポリシーと制限 – G Suite 管理者 ヘルプ
https://support.google.com/a/answer/6099642?hl=ja
今回の問題については言及されていませんが、ポイントは、G Suiteの各種上限値は予告なく変動するということです。
G Suiteの上限を触ったために操作停止された
cloudpackの規模は大きくなっています。社員数も増えています。案件も増えています。素晴らしいことではないですか。
ところがそのお陰で、1回のグループ操作で追加されるユーザーの数も増えまくって、さらに1日に追加するグループの数も増えまくったために、まさかの停止処置というわけです。
結果的にBackofficeの業務は停止、新規AWSアカウントが発行できずに構築チームの業務も行われず、今後会社規模が大きくなり続けると想定した場合、毎日停止する可能性もあり、ということはもはや廃業なのでは。
シンジ、役員陣に連絡
シンジ「Googleとは戦えないYO」
役員陣「金で解決しろ（ぇｗ」
シンジ、Slackで全員に知恵を借りる
シンジ「助けてハイパーエンジニアたちーｗｗｗｗ」
全員「Google買収だな」
シンジ、Googleマスターのハンズ長谷川さんに相談
シンジ「長谷川さん、金ならあるぞ、なんとかならぬか」
長谷川さん「グーグルころすとか新しいなうけるｗｗｗ」
ふっきれた
これだけ数多くのハイパーエンジニアに相談した結果これってことは、もう死ぬしかないってことか。ってことはGoogleをどうこうしようというのは間違いってことだな。
って思ったので、ひらめいた。
シンジチームの開発メンバーを会議室に招集。19時過ぎ。
久しぶりにホワイトボードで書き書きしてみる
俺は天才か。
(1)
- Route53でサブドメ切る
- サブドメでG Suite 契約する
- サブドメG Suiteの管理者は情シスの一部
- メインG SuiteでサブドメG Suiteからくるメールの受信用グループを作成する
(2)
- adminpackのロールでBakofficeの場合は「AWSアカウント作成」ボタンを作る
- 入力フォームに新規AWSアカウント用メールアドレスなどの必要事項を入力する
- 確認ボタン押す
- SlackでBackofficeのメンバーに確認、申請される
- 承認ボタンをBackofficeの誰かが押すと、サブドメG SuiteのAPIが発火する
- どの作業に対して誰が申請して誰が承認したかもSlackに流れる
- サブドメG Suiteで新規グループが作成され、メインG Suiteグループに転送される設定が自動で投入
ここで書いているadminpackとは、AWSアカウントをいい感じに管理してくれるWebサービスです。自社製ですが、販売しているので欲しい人は適当に連絡して下さい。今のところ超大手さんしか導入していませんが。。。そもそも大量にAWSアカウント持ってるケースが少ないね！
ここで20時。すっきりしたので帰宅。
ちなみに、単純にメール転送すりゃいいじゃんと思う方もおられるかと思って書きますが、メール転送はシステム的に禁止にしてあります。会社のメールが個人のメールアドレスに転送できるとか禿げそう。
そしてグループの数どんだけあんのよって話にもなりそうなので書きますが、具体値書くと怒られそうなので、ふわっと書くと、5桁は無いです。
そして現在、翌日の午前10時
未だにエラーであった。24時間経過してもダメならもっかいGoogleに聞いてみようかな。
並行して開発を進めよう。
それまではどうしたらいいのか。
そしてなぜメールは死なないのか。
とりあえず踊るか。
