継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

SRE NEXT 2022 Day1 参加レポート #srenext

SRE レポート

タダです.

SRE NEXT 2022 の Day1 参加レポートを書いていきます.自分が聞いたセッションでのメモを転記しながら感想を書きますが,私用の関係で最後まで参加できていないところがあります 🙇

sre-next.dev

How We Foster "Reliability" in Diversity

SRE as Service で他社の SRE プラクティスを実践してきた経験からどのように組織で SRE を実践.組織に適した SRE を定義して育てていくための取り組みの紹介するお話でした.SRE の実践の5つのステップは自分が体感したものと合致したので納得感があったり,組織変革のためのアプローチで MVV の作成や環境変化に伴うためのアプローチで組織の多様性が役立つというのは新たな気づきを与えてもらったセッションでした.

sre-next.dev

資料

メモ

  • 適切な SRE の実践がなぜ難しいのか
    • SRE に求められるものが多様化している
      • 組織ごとに信頼性が異なる(サービスを取り巻く全ての要素が同じにならない)
      • 信頼性の計測方法も異なる
  • システムの特性によって信頼性が異なる(緊急速報とコーポレートサイトの比較)
    • 短距離じゃなくて長距離
  • 技術的な側面と文化やプロセスなどの組織的な課題が関わる
    • SRE は組織の変革を伴うから一朝一夕にできない
  • SRE の実践の取り組み
    • SRE の実践における5つのステップ
    • 組織が自律的に動けるようにする
    • 組織の氷山モデル
      • 組織変革は上からも下からもアプローチが必要
      • Level3 からのアプローチ
    • SRE の方向性と価値観を明確にする
      • SRE のミッション、ビジョン、バリューを定義する
    • 企業・組織コンテキストの把握
      • 会社の方向性と SREs の MVV を合わせる
      • 企業活動を俯瞰的に捉えて,SRE の影響のある主要な変数を整理する
      • 様々なリソース：企業方針/サービス/組織のコンテキストを把握する
  • MVV 作成のステップ
    • 関係者へヒアリング
    • たたき台作成(8割位作る)
    • レビュー&修正
      • 大枠を固めたら使う言葉の選定やニュアンスの確認を同期的に行う
    • KPI
      • 文化情勢のためのMVVを作るだけでなくKPIを定めていく
  • 環境の変化に対してどのように取組むか
    • サービスによって適切な信頼性は変わるので変化の対応するための良いアプローチがないか模索
    • SRE 本 18.3.5 チームの力学 では多様性によってチームの問題点への盲点をなくす
      • 組織の環境変化への耐性を保つために組織の多様性が役立つ

SRE の歩き方・始め方

Q&A 方式で SRE とは？実践の仕方の紹介のセッションでした.特に Toil 削減の話は SRE 本でも見て実施していく必要があると思っていましたが,なぜやるのかの部分で改めて SRE の時間の確保だけでなくキャリアの停滞や燃え尽きなどの悪影響を見て,自動化できるものはしていく必要があると再認識しました.

sre-next.dev

メモ

  • そもそもSREとはなにか？
  • SRE は 2004年からGoogleにチームが発足
    • サーバー/MW のセットアップをソフトウェアの課題として扱う
    • オペレーションに正しくエンジニアリングを取り入れて改善し続けること
      • システムが安定してればいいというのではなく,数字でコントロールする
      • 手作業を行わず自動化してサービスをスケールさせていく(人を増やすのではなく)
  • SRE と DevOps の関係とは？
    • 同じ課題を別のアプローチで解こうとしている関係性
    • Dev/Opsのサイロ化という課題を解消しようとする側面がある(オペレーションをソフトウェアとして扱う、DevとOpsを分業するのではなく協業していく)
      • class SRE implements DevOps
    • SRE のプラクティスはDevOpsの範囲外(TOILの削減)範囲内(Dev / Ops の協業体制)の具体的な手法が提案されている
  • class SRE implements DevOpsを踏まえ、どういう形で SRE の実践・プラクティスを実践するか
    • SLI/SLO & Error Budget -> 信頼性のプラクティス,Window: SLI/SLOを評価する期間
  • SLI/SLO , Error Budgetの決め方
    • SLI :何らかの割合となるように値を定める
      • サービスや事業の目標と関連するような指標を定めるといい
      • サービスステークホルダー目線にもそったものにして、指標の状況に沿って開発の課題も向き合えるようにすると良い
    • SLO: 高い値を目指しすぎないこと
      • 開発速度とサービスの信頼性をうまくコントロールできるように値を調整
    • 大事なこと:サービスのステークホルダーや関係者と合意を取りながら決めること,決めたものを改善し続けること
  • Toil はSREのエンジニアリングの時間を奪うものになるので削減していく
    • ほっとくと増えるからSREの作業の50%未満になるように意識する
    • Toil はすべて解消しないと、仕事の時間を確保できないし、キャリアの停滞、燃え尽きなどの悪影響
      • 解消しなくてもいいものも多少はあることを受け入れる
  • ポストモーテムは組織全体がインシデントから学ぶフロー
    • ポストモーテムをかく基準や文化の醸成が必要
  • SRE プラクティスを組織に導入するためにきをつけること
    • SRE がエンジニアリングができるようにすること
  • 実践例として Embeded SRE がある
    • 開発チームに SRE が入ることで開発側からすると SRE の実践をそばで見れる
    • 開発チームの事情も SRE がチームに持ち帰れる

事業の成長と歩む、ABEMAのSRE探求の歴史

SRE のプラクティス実践における活動の中での行ってきたこと,振り返り,そこから改善したことをユースケースで知ることができました.SRE の実践は小さく初めて素早く失敗する大切さと関連するステークホルダーとの関係性を考えつつ進める必要があると感じた事例セッションでした.

sre-next.dev

メモ

  • ABEMA のサービス紹介からチームとして活動してきたことと今後について
  • SRE チーム発足の背景
    • 24/365だから障害時のインパクトが高い
    • 映像の通信トラフィックが多いので、物理的な限界を考慮する必要あり
    • 様々なデバイス対応しているため、デバイスに応じて品質維持
    • サービス、組織規模、システムの巨大化に伴いサービス品質維持しつつ、事業成長に伴ったシステムをスケールするためのチーム発足
  • 2018~2020年の活動
    • 横断的な活動をして、アジリティとプラクティスの導入をやった
      • マイクロサービスも非常に多くあったので,SRE だけで品質担保が難しく開発プロセスを含めていった(Production Rediness Checklist 作成)
      • キャパプラを開発チームに移譲
      • On-Callからの離脱(自律性向上)
      • SRE 文化の推進
    • 多くの課題が発生
      • 開発チームのリソースが確保できない
        • 開発チームのベネフィットを意識すること(アジリティと信頼性を保つ)
      • システム構成が少しずつ不明
      • リスク把握のコスト増
      • SRE チーム内で優先度が決めづらい
        • 兼務は難しい
  • 2021年〜現在の活動
    • 体制変更の実施
      • クラウド基盤のチームと SRE のチームを分離
      • 開発チームの中でも SRE の実践メンバーを抽出
    • SLI/SLOの先導
      • リクエスト数の少ないサービスでのアラート調整
      • 新しい計測手法の導入
      • 設定の簡略化
      • 効果としてサービス全体を俯瞰して品質が把握できるようになった
    • インシデント関連
      • インシデントへの参加やポストモーテムの先導を通して,インシデントフロー見直し,障害レベルの設定や障害を先導する Bot の開発
      • 効果として組織全体の障害への練度上昇
    • モニタリング課題の解決 *フロントエンドにおけるモニタリング強化するために要件,検証して New Relic 導入
      • 効果として広い範囲での可視化,アラート対応がフロンエンドエンジニアだけでできるようになってる
  • 今後として FIFA の無料放送を行うことになったので負荷対策や障害対策をしていく

LegalForceの契約データを脅かすリスクの排除と開発速度の向上をどうやって両立したか

プロダクトで重要なセキュリティの管理と開発のアジリティを維持しながら顧客への価値提供を行っていくための取り組みを紹介するセッションでした.セッション中に出てきた認知過負荷という言葉を初めて知り,組織スケールや扱うプロダクトの複雑性が増してくると発生しそうで早めに手を付けて改善しとかないと手がつけられなくなりそうだなと思いました.自分が遭遇したら改善や明瞭にすることを図っていきたいです.

sre-next.dev

  • 契約データの重要性
    • 第三者へ漏洩すると犯罪に発展する可能性がある
    • インサイダーや詐欺などの悪用される
      • 契約データは最優先で保護する必要があるが、開発上の課題がある
  • 認知過負荷の課題
    • 変更に対するリスク制御が困難、リスク肥大化のおそれ
    • 変更時や動作確認テストの工数増大 -> デプロイ頻度低下 -> 顧客への価値提供低減
  • 認知過負荷に対する取り組み
    • 守るべきものの定義
      • PRR & Premortem(大きめの機能開発時に実施)
        • PRR:機密情報の有無、リスク
        • Premortem:扱う機密情報が漏洩しないかの議論
      • ガードレールの導入
        • AWSのサービスで実施(アカウント分離,SSO,監査ログ基盤に集約 etc)
      • 人の権限情報のコード化と自動デプロイ:誰でも閲覧・編集できるような状態にするため
      • 既存の権限内容の簡素化:条件分岐図と真理値表、論理式を書いて実装に落とす
        • 認知負担がへった
        • 環境差をなくす
  • 実践の効果
    • 開発者に体験向上した点をヒアリングして,認知的負荷の低減を確認

一人から始めるプロダクトSRE

プロタクト SRE のロールを持っているのは1人だけという状況で現場に合わせて意思決定を行ったり,目の前の課題解決,SRE 立ち位置の定め方,メンバーの巻き込み方を紹介のセッションでした.

sre-next.dev

資料

メモ

  • クラウド勤怠の場合
    • 最初のSREとしてはいった
    • 開発者はSREにコンバートする余裕はなく、経験している人もいない
  • 現状把握 *ドメイン知識やチーム状況を把握 
    * チームの課題状況を観察する
    • 運用ペインが発生している可能性があるので理想と実態とのギャップを埋める
      • 無差別アラートによって開発者生産性が低下
      • 適切なモニタリングを行うのをやる
  • プロダクトチームへの安心してもらうための取り組み
    • SREの責務 -> どうプロダクトに関わらるのか、誤解があれば解消
    • 在り方を伝える -> ミッションを決める
    • SRE1人問題への向き合う
      • Core? Embederd? Enabling? => Enabling を選んで取り組んだ
  • Enabling SRE としてやってきたこと

まとめ

Day1 で参加したセッションとそのメモ,所感をまとめてみました.運営の皆さん,登壇された皆さん，お疲れさまでした！Day2 も楽しみ！

Day1 の公開された資料

直接セッションを見に行けてないですが,公開された資料のリンクもまとめていきます.

TypeScript で GitHub GraphQL API を叩いてみた

TypeScript GraphQL GitHub

タダです.

GitHub GraphQL API を叩く機会が初めてあったのでこの記事に備忘録としてまとめていきます.

前準備

事前準備として GitHub アクセストークンを発行します.権限として下記のものをつけます.

  • repo
  • admin:org read
  • admin:repo_hook read
  • user
  • admin:gpg_key read

https://docs.github.com/ja/graphql/guides/forming-calls-with-graphql

試したコード

dependabot アラートにあるものをリストするようなコードを書いてみました.ライブラリとして @octokit/graphqlを使っています.クエリで使っているパラメータはドキュメントを参照して設定しています.

github.com

コード抜粋

const QUERY = `
  query getVulnerabilityAlerts($org: String!, $repo: String!) {
    repository (name: $repo, owner: $org){
      vulnerabilityAlerts(last: 100, states: OPEN) {
        nodes {
          createdAt
          vulnerableRequirements
          securityVulnerability {
            package {
              name
              ecosystem
            }
            advisory {
              ghsaId
              publishedAt
            }
            severity
            package {
              ecosystem
              name
            }
            updatedAt
            vulnerableVersionRange
          }
        }
      }
    }
  }
`;

async function main() {
  try {
    const result:any = await graphql(QUERY, {org: `${process.env.org}`, repo: `${process.env.repo}`});
    const detailResult = result['repository']['vulnerabilityAlerts']['nodes']
    console.log(detailResult)
  } catch (err) {
    console.error(err);
  }
}

下記の FastAPI のセキュリティアラートをリストした場合の出力例です.

出力例

[
  {
    createdAt: '2022-01-29T08:39:43Z',
    vulnerableRequirements: '= 0.65.1',
    securityVulnerability: {
      package: [Object],
      advisory: [Object],
      severity: 'HIGH',
      updatedAt: '2021-06-09T13:34:55Z',
      vulnerableVersionRange: '< 0.65.2'
    }
  }
]

まとめ

簡単に TypeScript で GitHub GraphQL API を叩いてみたのでまとめました.これを dependabot の運用でアラートが滞留しているリポジトリや新規のアラートを気づけてない場合にコードを上げるたび都度通知するような GitHub Actions に利用できたら良いかもしれません.

参考記事

maku.blog

Datadog の GCP インテグレーションを設定する

Datadog GCP

タダです.

Datadog の GCP インテグレーション設定をしたのですが,備忘録でこの記事にまとめていきます.

GCP インテグレーション設定方法

ドキュメント記載の通り,GCP のサービスアカウントの発行と API の有効化が必要です.

docs.datadoghq.com

1,API の有効化

API の有効化するのは Stackdriver Monitoring API,Compute Engine API,Cloud Asset API を有効化を行います.いずれか1つでも有効化できてないと後続のサービスアカウントの鍵アップロードで失敗します.

2,サービスアカウントの作成と鍵のダウンロード

サービスアカウントを新規で作成します.権限として Compute 閲覧者,モニタリング閲覧者,Cloud Asset 閲覧者をアタッチし,鍵を JSON 形式でダウンロードしておきます.

3, Datadog GCP インテグレーションにサービスアカウントの鍵をアップロード

サービスアカウントの鍵を GCP インテグレーションの Configuration タブで Upload Key File を押してサービスアカウントの鍵をアップロードします.その後,Update Configuration を押した後, Service account successfully updated! が出れば成功です.

まとめ

ドキュメントの通りに進めていれば成功するのですが,API の有効化をし忘れてハマったので備忘録として記事にしました.

Security Hub から通知された『Lambda function policies should prohibit public access』に対応する

AWS Lambda Security Hub 運用

タダです.

業務で Security Hub から [Lambda.1] Lambda function policies should prohibit public access というアラートが飛んできました.対応してアラートを消したのですが,その対応を備忘録として書いておきます.

アラートの原因

アラートの原因は S3 イベントから発火する Lambda のリソースベースポリシー の設定が下記のようになっていました.

ポリシー例

{
    "Version": "2012-10-17",
    "Id": "default",
    "Statement": [
        {
            "Sid": "lambda-allow-s3-my-function",
            "Effect": "Allow",
            "Principal": {
              "Service": "s3.amazonaws.com"
            },
            "Action": "lambda:InvokeFunction",
            "Resource":  "arn:aws:lambda:ap-northeast-1:123456789012:function:my-function",
             "ArnLike": {
                "AWS:SourceArn": "arn:aws:s3:::my-bucket"
              }
            }
        }
     ]
}

原因の分析

リソースベースのポリシーには、別のアカウントまたは AWS のサービスが関数にアクセスしようとしたときに適用されるアクセス許可が表示されます

ドキュメントをみていた際に上記引用文の説明を見て,リソースベースポリシーでは AWS:SourceArn でリソースを明示してかつどの AWS アカウントからアクセスが有るかをポリシーに記載する必要があるかと思い,下記を追記してみることにしました.

"Condition": {
    "StringEquals": {
       "AWS:SourceAccount": "123456789012"
},

リソースベースポリシーに AWS アカウントを追加する

アラートが発生した Lambda の 設定 > アクセス権限 > リソースベースのポリシー から S3 のポリシーを選択して編集を押します.編集画面でソースアカウントに S3 がある AWS アカウント番号を記載して保存すれば反映完了です.

この対応後 Security Hub からのアラートも収まったので,対応として適切だった模様です.

まとめ

Security Hub からの Lambda に関するアラートを初めて対応したのでその模様を記事にしました.Security Hub のアラートの対応が初めてだったしリソースベースポリシーがどう影響するのかを学べた経験になりました.

terraform-provider-aws v4.9.0 のリリースで破壊的な S3 の変更がなくなったと聞いたので試してみた

AWS Terraform 運用

タダです.

terraform-provider-aws の v4 で S3 リソースの変更をどうやって行くかなと思っていた頃に v4.9.0 で S3 の破壊的変更がなくなったという話がでてきたので,試した内容をまとめていきます.

resource/aws_s3_bucket: The acceleration_status, acl, cors_rule, grant, lifecycle_rule, logging, object_lock_configuration.rule, policy, replication_configuration, request_payer, server_side_encryption_configuration, versioning, and website parameters are now Optional. Please refer to the documentation for details on drift detection and potential conflicts when configuring these parameters with the standalone aws_s3_bucket_* resources.

github.com

provider のバージョンを 4.9.0 にあげたときの挙動

v4.9.0 が出た時にドキュメントに下記の引用文が追記されていました.4.9.0以降に上げることが推奨されています.

Versions 4.0.0 through v4.8.0 of the AWS Provider introduce significant breaking changes to the aws_s3_bucket resource. See S3 Bucket Refactor for more details. We recommend upgrading to v4.9.0 or later of the AWS Provider instead, where only non-breaking changes and deprecation notices are introduced to the aws_s3_bucket. See Changes to S3 Bucket Drift Detection for additional considerations when upgrading to v4.9.0 or later.

それでは実際にどんな挙動になるかを確認していきます.プロバイダーの指定を ~> 4.9.0 に変更後,terraform init および terraform plan を実行してみました.以前の記事で書きましたが,S3 の破壊的変更によって terraform plan をするとエラーがでていたのがでてなくなりました! その分 Warning: Argument is deprecated という警告がでるようになりました.

terraform-aws-provider 指定箇所抜粋

terraform {
  required_version = ">= 1.0.0"

  backend "s3" {
    encrypt        = true
    bucket         = "hoge"
    key            = "hoge.tfstate"
    region         = "ap-northeast-1"
  }

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.9.0"
    }
  }
}

provider "aws" {
  region = "ap-northeast-1"
}

terraform init および terraform plan の実行結果

$ terraform init
Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file
- Installing hashicorp/aws v4.9.0...

- Installed hashicorp/aws v4.9.0 (signed by HashiCorp)

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
$  terraform plan
~中略~

No changes. Your infrastructure matches the configuration.

Your configuration already matches the changes detected above. If you'd like
to update the Terraform state to match, create and apply a refresh-only plan:
  terraform apply -refresh-only

Warning: Argument is deprecated
│ 
│   with aws_s3_bucket.v4_test,
│   on s3.tf line 9, in resource "aws_s3_bucket" "v4_test":
│    9: resource "aws_s3_bucket" "v4_test" {
│ 
│ Use the aws_s3_bucket_server_side_encryption_configuration resource instead

今回の変更に対する所感

v4.9.0 になったことで aws_s3_bucket リソースの変更を最悪行わなくてもプロバイダーバージョンのアップグレードを行えるようになったのですが,ドキュメントを見ると v5 になると aws_s3_bucket のパラメーターが削除されるためいずれにしても aws_s3_bucketで設定したパラメーターを分割せざるを得ないのだなと...暫定的な処置として v4.9.0 にあげた後でもリソース分割対応に向き合わなければなりません😇

  • acceleration_status
  • acl
  • cors_rule
  • grant
  • lifecycle_rule
  • logging
  • object_lock_configuration
  • policy
  • replication_configuration
  • request_payer
  • server_side_encryption_configuration
  • versioning
  • website

ドキュメント記載文

In the next major version, v5.0, the parameters listed below will be removed entirely from the aws_s3_bucket resource. For this reason, a deprecation notice is printed in the Terraform CLI for each of the parameters when used in a configuration.

registry.terraform.io

v4.9.0 にあげるための対応まとめ

v5 の事情を踏まえ業務で v4.9.0 にアップグレードしました.最後にその大まかな流れを備忘録としてまとめます.

  1. terraform-aws-provider を v4.9.0 にして terraform init で初期化
  2. tfrefactor で S3 バケットリソースを分割
  3. terraform plan で確認するとリソース分割した対象が差分として表示されるため,terraform import で差分を埋める

そして,その時に使った terraform import コマンド例です.

terraoform import コマンド例

$ terraform import aws_s3_bucket_acl.hoge hoge-bucket,private
$ terraform import aws_s3_bucket_lifecycle_configuration.hoge hoge-bucket
$ terraform import aws_s3_bucket_versioning.hoge hoge-bucket
$ terraform import aws_s3_bucket_cors_configuration.hoge hoge-bucket
$ terraform import aws_s3_bucket_server_side_encryption_configuration.hoge hoge-bucket
$ terraform import aws_s3_bucket_website_configuration.hoge hoge-bucket
$ terraform import aws_s3_bucket_request_payment_configuration.hoge hoge-bucket
$ terraform import aws_s3_bucket_replication_configuration.hoge hoge-bucket
$ terraform import aws_s3_bucket_policy.hoge hoge-bucket 
$ terraform import aws_s3_bucket_object_lock_configuration.hoge hoge-bucket
$ terraform import aws_s3_bucket_logging.hoge hoge-bucket

まとめ

terraform-provider-aws v4.9.0 の変更点とその影響,自分が実際にv4.9.0にアップグレードしたときの作業を簡単にまとめました.これまで業務で terraform-aws-provider をあげたことがなかったので,今回は勉強になりました.今度は v5 系が来るだろうと思うので情報収集や検証をしていければと思います.

関連記事

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com