目の前に僕らの道がある

勉強会とか、技術的にはまったことのメモ

AWS Control Towerを調べる

これは 3-shake Advent Calendar 2022 10日目の記事です

仕事の中でAWSで複数のアカウントを管理したいという要件あり、その中でAWS Control Towerが使えないかなと調べたものをざっくりと書いていきます。

AWS Control Towerとは

AWS Control TowerとはLanding Zoneを実装するためのAWSのマネージドサービスです。そもそもLanding Zoneって何って話になりますね。

Landing Zoneとは

セキュリティとコンプライアンスのベストプラクティスに基づきアーキテクチャ設計とマルチアカウント環境を管理する仕組みを指します。

Landing Zoneは、下記機能から構成されます。

  • アカウントの発行
    • 必要な初期設定の済んだアカウントを作成
  • 管理用権限の発行
    • 対象アカウントを管理するための権限を作成
  • AWS ログの集約
    • 監査用ログをセキュアに一元保存
  • ガードレールの設置
    • 実施してはいけない操作の禁止
    • 危険な設定の監視

Landing Zoneの実装方法

AWS Control Tower

AWSサービスとして提供される Landing Zoneです。容易に利用可能ですが、カスタマイズするには制限があります。(必須のガードレールを外せなかったり)

主にこれからAWSを利用する場合に利用できます。既存アカウントにも適用可能です。

独自実装の Landing Zone

自組織で独自実装するパターンです。自組織の方針に従って自由にカスタマイズできるのが強みです。ただし、自由にカスタマイズはできますが、自身でメンテナンスしないといけないので、コストはかかります。

主に既存アカウントに適用する場合に利用できます。自組織でアカウント発行の仕組みや管理の仕組みができあがってる場合などです。

そもそもなんでマルチアカウントにするのか

AWSをマルチアカウントにする観点として以下のものが考えられます。

  • 環境の分離
    • 開発、テスト、本番を分離することによるセキュリティおよび統制の確保
  • 請求の分離
    • 部門やシステム単位でのコスト明確化
  • 権限の分離
    • 部門間での権限分離およびアカウントへの権限移譲
  • 複雑性の分離
    • アカウントの目的を明確に絞ることで、構成がシンプルになる

AWS Organizationsだけでもできること

マルチアカウント管理するだけならOrganizationだけでもある程度はできます。むしろAWS Control TowerはOrganizationの機能を利用しています。

AWS Control Towerだと何ができるのか

Control Towerで提供される機能として以下のものがあります。

  • Landing Zoneの提供
    • AWS Organizationを使用してマルチアカウントを作成
      • デフォルトでSandbox、SecurityのOUを作成
    • AWS IAM アイデンティティセンターを利用したID管理を提供
  • Account Factory
    • AWSアカウントのプロビジョニングの自動化
    • 設定可能なテンプレートを提供
  • CloudTrailとConfigログの保存
    • Log Archiveアカウント内のS3バケットに一元的に保存される
  • ガードレールの提供
    • 必須と任意の観点の2種類と予防的と発見的の2種類の組み合わせがありControl Towerにより管理下のアカウントに適用される
    • 参考: ガードレールの仕組み
    • 予防的ガードレール(Service Control Policy)
      • 禁止されたアクションの実行が拒否される仕組み
        • Control Tower管理下のアカウントは必須の予防的ガードレールで禁止されているアクションが不可能
    • 発見的ガードレール(Config)
      • 特定のイベントが発生したときにCloudTrailに記録される仕組み
  • ダッシュボード
    • OUやアカウント、ガードレール違反などが一覧表示できる

AWS Control Towerではできないこと

AWS Control Towerでは提供されてない機能もあります。GuardDutyやSecurity Hubなどのセキュリティ機能を組織全体適用するにはOrganizationsの機能を利用する必要があります。

AWS Control Towerの注意点、制約事項

いろいろ資料を見てみてこの辺注意が必要かなという点を書いていきます。

注意点

制限とクォータ

  • S3へのログの保存期間は、最大15年間保存可能(最近アップデートされた)
  • Security OU の共有アカウントの E メールアドレスは変更可能だが、これらの変更を AWS Control Tower コンソールで確認するには、Landing Zone を更新する必要がある
  • AWS Control Tower Landing zone の OU には、OU あたり5個のSCPの制限が適用される
  • 300超のアカウントを持つ既存の OU は、AWS Control Tower に登録することはできない
    • 300を超える場合はOUを分ける必要がある
  • OUのネストは2段階まで、孫OUを持つことはできない

AWS Control Towerを使うべきなのか

マルチアカウントを展開していくのであれば、AWSのベストプラクティスに乗れるので、使用するのが無難です。

ただし、独自のLanding Zoneをすでに構築しており、Account Factoryの仕組みも独自で構築できているのであれば、移行コストを鑑みてそのままでも問題ないです。

必須の予防的ガードレールが許容できない、OUなどの制限にひっかるなどの運用上の制約がある場合は使えないので、組織のポリシーを見直すか、独自でLanding Zoneを作るかを考える必要があります。

発展

もっと調査したかったが、時間が足りなかったことや今後調べたいことです。

コンソールからAccount Factory実行するとService Catalogの設定項目がありますが、Service Catalog自体の理解不足でどう扱うのかが把握できてないのでこの辺調べたいです。

Account Factory for Terraform(AFT)を使うとアカウント発行そのものもIaC化できるので試したい。

Customization for Control Tower(CfCT)を使うとアカウント発行のイベントをトリガーにCloudFormationを実行できるので、これも実験したい。

まとめ

Control Towerについて調べたことを書いていきました。

実運用自体はまだしてないので、これから触ってみて知見が溜まってきたらまたそれも共有できたらと思います。

2022年10月のふりかえり、まとめ

7年ぶりにふり返りするような気がします。これぶりですかね。

blog.masasuzu.net

10月は思い立って細かいことでも記録に残すようにし始めたのでサブブログの月間投稿数が増えてます。このまま続けたいところです。メインブログは相変わらず0なのでちゃんと書きたいところではあります。

仕事

10月は端境期だったので、技術検証をメインでやってました。

技術

メインブログの方はどちらかというとパブリック向けに書いてます。ただ、この方針だと記事がゆるい記事が書きにくくなってきたので、サブブログを作った経緯があります。

サブブログの技術記事は他の誰かのためではなく未来の自分が思い出すために書くをモットーに書いてます。なのでゆるく、細かい系のことも気軽に書いてます。分からないことは分からないと明示する。途中でも経過を残す。恥も残す。そんな感じです。

以前とくらべてGoogle Cloud回りを10月はいじってた感じですね。

資格

PCA取りました!

11月にはPCAKCNA、年内にCKACKADを取ることを目標に業務とは別に学習してます。なお、業務ではGoogle CloudもKubernetesも今のところ触る余地ないです。が、将来の投資として学習してます。近い未来で使うのが目に見えてるので。

土曜日の午前中に温泉入るのにはまってます。休日の早い時間に行動すると時間の有効活用ができるなとしみじみ感じてます。

生活

寒くなりましたが、がんばります。

11月に向けて

といっても11月始まってますが。

11月は資格の勉強もあるし、新しい固めのお仕事も始まるので、だいぶヘビーになる予感を感じてます。

寒くなる季節なので体調には気を付けつつも、引き続き温泉につかり、ブログ書くのも続けて行きたいですね。

吉祥寺.pm29で久しぶりにLTしてきました #kichijojipm

kichijojipm.connpass.com

久しぶりにLTしてきました。

こんなこと考えてたら良いタイミングできちぴーが開催されるので、LT申し込んでみました。

どうやら7年ぶりだったみたいです。

タイミング的に最終出社日の翌日だったので、キャリアの話をしました。

diary.masasuzu.net

正直、LTにおさまる量じゃなかったのは反省点です。資料ももうちょっとなんとかできたかなあという気持ちがあります。少しずつ登壇回数増やして、勘を取り戻していきたいところ。

JAWS-UG SRE支部 #2 突撃!となりのSRE

jawsug-sre.connpass.com

聞いてきましたのでメモと感想を残しておきます。

LT

マネーフォーワードのマイクロサービス基盤のこれまでとこれから by マネーフォワード @grezarjp

マネーフォワードのマイクロサービス基盤の移り変わりの紹介。中央集権構造 => 権限移譲フェーズ => これから

  • 中央集権構造
    • サービスごとに開発チームが存在、サービスにまたがってインフラチームが存在
    • 開発チームはインフラを気にしなくてもすんだ。メンバーが少ないうちはなんとかなった
    • 組織の規模に対してインフラチームがスケールしなくなった
    • 責務の分解点を再定義 DevOpsへ
  • 権限移譲フェーズ
    • 開発チームに権限を渡していく
    • AWSとKubernatesを使用
    • ランタイム、ミドルウェアも開発チームが管理
    • サービスごとにNamespaceを切る、Namespace内で開発チームは権限を持つ
    • マイクロサービスごとにAWSアカウント管理して、リソースを管理する
  • これから
    • 権限は渡したが、運用まではむつかしい
    • 開発の運用を負荷を下げるために
      • Terraformのモジュール化、設定のバリデーションの整備
      • AWSアカウントの統制、コスト可視化を進めたい
      • アプリケーションランタイムのSnadbox化
        • 特殊要件なアプリケーションで使えるように

開発チームにここまでインフラの権限を渡せて、運用できるのはすごいなと思った。

  • QA
    • Q: 開発チームの権限移譲の苦労、運用面、技術面
    • A: マルチアカウントをつかって 技術上の考慮点があった
    • 人と人とのかかわりに関しては銀の弾丸はないので、地道な作業が必要
    • ドキュメントとかで監視項目を揃えてあげるのに力を入れた
    • Q: 開発とインフラでスキルセットの違いはあった?
    • A:インフラはアプリをあんまり見てこなかったのでそのへんのギャップはあった
    • Q: EKSのテナント分割の単位
    • A: 権限分類と障害の影響範囲の最小化はシングルテナントが有利とは言われるが
    • 運用負荷を下げるためにマルチテナントを選んだ

SREグループのマネージャーという立場になって真っ先にやったこと by ミクシィ@isaoshimizu

内容に関しては、スライドに詳しく書いてあるので参照。

SREのミッション・バリューいいなあと思った。うちのチームでもちゃんと考えたい。

SRE Lounge #13 LTでも今回と近いことを書いてるので参照してほしいとのこと↓

組織にSREの文化を作り上げていくEnabling SRE | Money Forward Engineers' Blog

  • QA
    • Q: SRE主導でやるべきではなかったこと
    • A: SREは万能な人がおおくでできてしまう
      • 開発側のリソースが足りなくて急がないといけないことをSREがやってしまう
      • 本来はそうじゃないよねって話

自分としては、SREでも開発分野でも巻き取れることはやってしまってもいいと思うんですよね。線を引きすぎるとセクショナリズムになってあまり良くない気がしてる。組織のあり方はそれぞれで、コンテキスト分かってないので、言い切ることはできないですが。

Containerサービス と Toil と by スリーシェイク  @tt0603

ECSとEKSについてToilと紐付けての話題。

  • Toilの削減ステップ
    • 特定
    • 計測
    • 削減

ただこのプロセスはつらい。

SREとしては長期的なエンジニアリング に時間を使いたい。本質的なことをすることが目的。Toilを削減することが目的ではない。

技術選定として、まずマネージドで考える。チームとして何を大事にしているかを考える。自分たちの”サイズ”で技術選定をして価値あるエンジニアリングをする。

個人的にはEKSとECSのまとめがわかりやすくてよかった。

  • QA
    • Q: セルフホステッドを選択する場合は?
    • A: 監視するとき Prometheus使うときとかつらいので
    • Fargateは起動が遅い スケールが遅い

パネルディスカッション

  • MFのSREの組織のやり方で工夫してるところ

  • 技術支援からSREの組織

    • 変数がいくつか システムの規模 性質 組織規模、レベル感など
    • pure sreではじめて権限移譲していく
    • 自分たちのサイズに合わせて組織を作っていく
  • 開発とSREのベストの距離感

    • タイミングによって違う固定されたものじゃない
    • 構成をいかにシンプルにできるかが大事
    • SREが開発に使いやすいサービスを提供する
    • SREのAPIを提供するので好きに使って的な
    • 横断組織SREと開発チーム内SREというパターンもある
    • お互いのコミュニケーションは大事
  • 採用する際に求めるスキルセットやレベル感

    • なんでもかんでも能力を持ってる人はいない。特定の領域に得意を持ってるといい、最低限のレベル感はほしい
    • コミュニケーション 大事 ソフトスキルの担保が大事
    • 会社のバリューにあってるか
    • SREワークブックの最後の方求められるスキル書いてある
    • すべてのインフラコードはIaCに寄せたい、チームにはソフトウェアスキル、インフラスキルそれぞれ持つメンバーがほしい
    • 変更時のトラブルシューティングはできるべき
    • コードレビューできるスキルを持っていてほしい
    • コーディングあるていどできる人
    • 組織による
  • 開発をSREに興味をもってもらうはどうしたらいいのだろうか

    • SLOを決めて共通言語で話す
    • 留学すると面白いかも
      • お互いがどういう観点で仕事してるかがわかってよい
    • どこまで開発に移譲するか
      • エラーバジェット、SLO、SLIは必要
      • SREが設定するSLOより開発者が設定するSLOの方がいい
      • 開発者にとってうまいところを教えるアプローチ
      • 開発者にとってもバグが出ないことによって、気持ちよく開発できるよ!

開発者の観点じゃなくてビジネス観点でSLO設定するんじゃないのかなって思う。。。?

あと、留学いいなあと思った。開発チームに留学したい。

  • SREチームが存在しない。どんなフェーズになったらSREチームを作ったほうがいいというしきい値あります?

    • 開発者が開発以外に手を取られて開発スピードが落ちてるのが目に見えたら
    • 兼務の限界値がある。得意なことにバリューを出せるようにしたい
    • 開発しながらAWSの新機能をキャッチアップするのはたいへん
    • devとopsのバランスが崩れているとき SREのプラクティスをいれるといいのかも
    • エラーバジェットが判断軸になるかも
    • どれくらいのチームが困ってるかが判断軸になる
  • Toil撲滅の意味で費用対効果高かったLambdaランキング

    • 今Lambdaを殆ど使ってない
      • chatbotが出たのでLambdaの役割を終えた
      • EKS上にアプリケーションを作ってしまうことが多い
    • 必要悪としてのLambda コードを書くのは最終手段。書いた瞬間に負債になる
    • 時刻でEC2終了するLambda
      • オートスケーリングでいいのでは?
    • terrafromでLambda扱いにくい問題
  • SREとしてセキュリティに対しての役割サービス

    • Inspector
      • ECRのイメージスキャン
        • CI/CD成立してからじゃないとイメージスキャンできない
    • GuardDuty
    • SSO
      • IAM Userを撲滅できた
      • ただ個別要件に対応しにくい
    • SREが見てるケースが多い
    • コーポレートセキュリティは範疇じゃないが、アプリケーションセキュリティは範疇
    • 5,6人目にセキュリティが強い人がほしい
    • 着想の段階からセキュリティの観点をいれておきたい
  • モニタリングロギングの観点で使用してるAWSのサービス

    • AMP
      • EKS使ってるので
      • コスパが良かった
    • CloudWatch log
      • 通知考えるとLambda使わないと
    • Athena
      • わずらわしい
      • 検索しにくい
      • Lokiとかに寄せたい
    • ログをどこにおく
      • S3

Lokiってこれかな?

雑感

他の会社のSREの話を今まであまり聞くことがなかったので、気づきを得る部分が多かった。SREのミッション・ビジョン・バリューはちょっと考えてみたいなと思った。

オンライン開催の形式はYouTube Liveがいいなあって思った。聞き逃しても巻き戻して聞き返せるのがすごい体験として良い。

Future Tech Night #20 Terraform State縛りの勉強会 #future_tech_night

future.connpass.com

久しぶりにちゃんと勉強会の感想ブログ書きます。

① State の分割戦略 〜ModulesとWorkspacesを利用して〜

StateはTerraform上での管理を分ける意味では非常に重要な要素であり、適切に分けることで不慮の事故や予期せぬ変更からクラウドリソースを守ることができます。このセッションでは演者が実際にTerraformを利用して感じたことを交えながら、適切なStateの分割戦略とは?について話します。

Stateの分割についてModuleによるアプローチとWorkspacesによるアプローチ、そしてそのあわせ技についての説明がありました。 Workspacesは使ったことないのであまり知見がなかったので、いろいろ参考になる部分がありました。

今のterraform運用だと環境ごとにディレクトリを切ってstateを分割してます。で、環境ごとの差異としてパラメータだけでなく、作るリソース作らないリソースが若干まちまちなので、そのままだとWorkspacesは向かないなと感じました。

絶対に作るリソース、RDSやVPCなどは分割した上でWorkspacesで管理するのはありなのかなとは思いました。ただ、同じシステムで、環境毎のディレクトリとリソース毎のディレクトリが混在するのはわかりにくくならないかなという懸念はあります。悩ましいですね

あと、ブランチ戦略も難しいですね。現状はmasterでprdをapplyするように、stagingでそれ以外の環境をapplyするようになってますが、全部masterでやるようにしても良いのではと思ったりもしてる今日このごろです。

クラウドリソース自体をdestroy/createdせずに、Terraformリソース定義の記述場所を変更する方法

クラウドサービス上で稼働するリソースには一切手を付けずに、Terraformの定義記載場所だけを変更する方法を話します。

Terraformを利用していると「このディレクトリ配置じゃダメだ。配置変えしたいのだけれど、リソースの再作成はできない。次にインフラ設計するときは、〇〇に注意しよう」という運用ナレッジが貯まると思います。スタート時点で完璧なTerraformディレクトリ設計ができれば御の字ですが、それが不可能なことは、この分野でベストプラクティスが確立されていないことにより証明されています。

本パートでは「Terraformのディレクトリ配置には定石がないのだから、運用状況に合わせて柔軟に配置換えすべき」という観点から、「動作中リソースに影響なく、Terraform定義箇所を移植する方法」について話します。

こんなふうに別のtfstateファイルにリソースをmvすることによって、Stateにリソースを移動できる手法を説明してました。

  1. terraform state mv -state-out=${moved_resource.tfstate} ${moved_resource}
  2. terraform state pull > ${to.tfstate}
  3. terraofm state mv -state=${moved_resource.tfstate} -state-out=${to.tfstate}
  4. terraform state push ${to.tfstate}

State間でのリソース移動に関しては、terraform state rmterraform importのあわせ技しか知らなかったので、新しい知見を得ました。まだ試せてないないんですが、State内での移動であれば、moved block使うのもありなのかなと思いました。ちなみリソースが消えた場合にもmove blockって使えるんですかね?


なかなか他の会社のterraform運用の話を聞く機会があまりなかったので、楽しかったですね。

最近勉強会出てもメモすら残さないことが多くて、せっかく参加したのにあまり有意義に時間を使えていなかったので、薄くてもいいので今後ちゃんと感想、意見を書き残していきたいと思いました。