akippaインフラ改善物語 Vol.2
akippaのインフラを改善していく物語の2回目です。実態は3回目、という事情は前回にも綴っていますが、まったくどうでもいいですね。
前回からのアップデート
Vol.1の投稿から3ヶ月弱、6月になってようやくAWSアカウントの分割が完了しました。
アカウント分割になぜそれほどの時間が？と思われるかもしれませんが、自社サービスの中の人をやっていると、日々の運用を回すために取り組むべき課題も多く、これらと格闘しながら何とかたどり着けたのが実情です。
Vol.1では「次回までにアカウント分割を完了させる」と息まいていたので、自己採点ではひとまず及第点です。
アカウント分割前後
再掲になりますが、アカウント分割は以下の背景・アプローチで実施しました。
分割前
課題だと捉えた点
同一アカウントに本番・テストのリソースが同居しているため、オペレーションミスの懸念がどこまでいっても拭いきれない
タグを利用していないので、コストの詳細が把握しづらく、積極的なコスト最適化やコストバランスの見極めが難しい
必要十分はVPC単位のisolationでカバーされていますが、より磐石なインフラを目指すには色々工夫が必要な状態でした。
分割後
課題は解決できた？
オペレーションミスの可能性は確実に低下
コストはアカウント単位で一目瞭然
より柔軟かつ安全な運用スタイルを構築できる
ファーストステップで狙っていた的は、概ね撃ち抜けたかなという手応えです。当然この状態がゴールではないので、これをベースに様々な改善を積み重ねていくのですが、それに伴い環境が完全に分離されているのは心理的なプレッシャーが全然違います。
ちょっとした検証や実験が、開発環境アカウントで気軽に行えるようになったのも大きいです。Service Quotasも環境ごとに考えれば良いので、頭を悩ませるものが1つ減って嬉しいかぎりです。
もし、この記事を読んでいただいた方で「AWSアカウント x 1のごった煮運用」をされていれば、是非ともアカウント分割をお勧めします。
続・ハマったポイント
Vol.1でお伝えした「ハマりポイントと解決方法」のtips第2弾です。インターネットは共有知、どなたかの参考になれば幸いです。
クロスアカウントのAuroraクローン制限
akippaでは以前から、ステージングDBの構築を以下のように行っていました。
本番環境のAuroraからクローンを作成
クローンしたAuroraの秘匿データをマスキング
2.を最新のステージングDBとし、古いステージングDBはリタイア
事前の調査でAuroraがクロスアカウントのクローンに対応していることは分かったので、上記の運用をそのまま踏襲できると楽観視していました。
ところが実際の移行前に検証してみると、初回のクローンは成功するものの、2回目以降のクローン(上記の3.にあたる手順)がエラーで失敗してしまいます。
これもドキュメントにしっかり記載があるのですが、クラスターのクロスアカウントクローンはAWSアカウントに1つしか作成できないという制限が、エラーの原因でした。
1 つの Aurora DB クラスターから最大 15 のクロスアカウントクローンを作成することができます。
15 のクローンは、それぞれ異なる AWS アカウントが所有する必要があります。つまり、クラスターのクロスアカウントクローンは AWS アカウントに 1 つしか作成できません。
初回はクローン先のAWSアカウント(=開発環境アカウント)にクローンが無いため成功し、2回目以降は初回に作成したクローンが既にあるため、この制限に抵触してエラーになる、という状態ですね。見事に踏み抜きました。
手順を組み替えて、クローン作成前に既存のクローンしたAuroraクラスターを削除すれば良いのですが、削除開始→(各種工程を含む)構築完了までダウンタイムが発生してしまいます。
本番環境ではないとはいえ、ステージング環境DBのダウンタイムは開発や運用に大きく影響するため、何とか回避する必要があります。
結果的には、従来のクローンでの構築は諦め、スナップショットベースの構築に舵を切りました。クローン時代は数分で完結していた作業が、スナップショットベース手順では30〜40分ほどかかるようになったものの、現在の運用では許容できるオーバーヘッドだと判断しています。
本番環境のAuroraでスナップショットを取得
作成したスナップショットを開発環境AWSアカウントと共有
開発環境AWSアカウントで、2.のスナップショットからAuroraクラスターを復元
以降はクローン時代と同じ手順
不要リソースの削除
これはハマったポイントというより、当初の想定より大変だったものです。
アカウント分割後は、本番環境で稼動していた開発環境用リソースはすべて不要になります。運用最適化やコスト観点から、これらの不要リソースは可及的速やかに削除してしまいたいところです。
この記事を書くにあたってあらためて確認してみると、削除対象リソースは191個ありました。これを機に、過去の用途不明バックアップなども削除しようと色気を出したのがマズかったのかもしれません。だって消したかったんんだもん。
こういうケースは泥臭く対処していくしかないので、対象リソースを地道にピックアップしました。最終的に別観点から比較検証できるよう、削除対象とみなしたリソースにはタグ付けし、Resource Groupsから一本釣り可能としておきます。
ここまで段取りすれば、一気に削除してしまう方法も色々あるでしょうが、対象サービスが多岐に亘っていた点と、本番環境のオペレーションであるという点を踏まえ、AWSコンソールでポチポチ削除していって無事完了です。
とはいえやはり、人力作業はできるだけコンピューターに頑張ってもらうというのがエンジニアの性分でもありますから、改善をもっと進捗させて早くIaCなどに取り組みたいところです。
次の取り組み
アカウント分割が完了し、ほっとひと息つきたいところですが、解決したい課題はまだまだあるので矢継ぎ早に次の課題へ取り組みます。
OS/言語ランタイムのバージョンアップ
AZ構成の見直し
次回の更新では、どこまで進捗できているか、楽しみにお待ちいただけると幸いです。
宣伝
noteのブログにとどまらず、akippaは「真のテックカンパニー」を目指して様々な取り組みを行っています。その中に akippa tech park というイベントの企画・主催があります。このイベントの第二回に、何の因果か登壇することになりました。
大阪でのオフライン開催ではありますが、少しでも興味があれば是非ご参加ください。