omuronの備忘録

個人的な備忘録

「AWS Expert Online JAWS-UG: Step Functionsの本気」 #awsxon 受講メモ

AWS 勉強会

AWS Expert Online JAWS-UG: Step Functionsの本気

jawsug-arch.connpass.com

見せてやるよ、Step Functionsの本気ってやつをな

アマゾンウェブサービスジャパン toriはらさん、下川さん

www.slideshare.net

Step Functions のかゆいところと改善策

  • JSON(ASL) でワークフロー書くのが大変？
    • arn もドロップダウンで出ない
    • Lambda が無いと先に枠（フロー）だけ書くことができない
  • Workflow Studio でビジュアルツールでワークフローが書けるようになった
    • ASL を抜き出せる
    • CFn に ASL を埋め込む元にできる
  • Python なれてたら Step Functions Data Science SDK で書ける
    • Jpyter Notebook で作れる
  • VSCode なら YAML で書けるようになった
  • CDK にも対応

Step Functions から呼ばれる Lambda のリポジトリ分け

  • 答えはない
  • Lambda の作成チームが別れているなら分ける
  • 一連の流れとして Start から End までマイクロサービスとして成立しているなら一つ
  • 切り分けのキーワード
    • ドメイン駆動設計
    • 境界づけられたコンテキスト
    • コンテキストマップ

Step Functions から呼ばれる Lambda 関数のデバッグは？

  • 昔なら CloudWatch Logs
  • Step Functions も Lambda も X-Ray に対応しているので、X-Ray とか
  • Local で先にテストしておく
    • Lambda handler を直接テストすべきでない
    • main.py も準備して事前確認できるようにする
    • ピュアなビジネスロジック部分をテスト
      • DynamoDB とかの Repository は、インターフェースにして切り離す
  • Lambda からエラーハンドリングを取り除くために Step Functions を使う
    • エラーやリトライは Step Functions で処理する

Step Functions の入出力処理の JSON path syntax はどうやって慣れる？

SF で復元力のある Fargate Task 実行って？

オンプレミス/外部 SaaS などのジョブとどうやって連携する？

  • Callback ワークフロー
    • Task token を払い出して SQS に積んで処理する
    • コンシューマーは SQS から Task token 入のメッセージを処理
    • SF の API に Task token をパラメータとして渡して戻す

並列ジョブはどうする？

  • SF に Map State があるので、配列の数だけジョブを呼び出せる
  • 複数ジョブを同時に実行するパラレルもある

SF を API に使えるか？

  • 軽量 ETL オーケストレーションとして使う
    • APIG から呼び出して、同期的にワークフローをコールする
      • APIG の29秒制限内で処理が終わるのであればできる
  • BFF として使う
    • APIG から BFF の処理を SF として作って呼び出す
  • 非同期パターンとして使う
    • WebSockets

デザインパターンの視点

コードフリーな世界観に浸りたい

  • SF が AWS SDK との統合をサポート
    • API 叩いたら AI サービスを実現など
  • EventBridge のターゲットに API Destinations を指定可能に
    • 任意のエンドポイントに HTTP リクエストを遅れる

まとめ

  • SF はサーバーレスのワークフロー
    • 利用した分課金
  • マイクロサービスをオーケストレーションしたいときに可視化されたワークフローを体験可能

所感

Step Functions は、サンプル実装しかしてない状況です。
API のバックエンドとしても使えそうなので、その方向で試したりはしてたのですが、使い方として間違ってなさそうで良かった。
全然なれてないので、もっと触らないと使いこなせなさそうです。

時間が過ぎてたけど、懇親会に突入したらちゃんとやってました。
@tcsh さん、@98lerr さんありがとうございましたー！

「AWS re:Invent 2020の現状おさらい、AWS2021 主要Updates 第一夜」 #awsbasics 受講メモ

AWS 勉強会

awsbasics.connpass.com

今週はお昼の「AWSの基礎を学ぼう」はお休みで、「AWS re:Invent 2020の現状おさらい」が毎日開催されます！
出れるのが確定してから勉強会には申し込むので遅れがちになるのですが、すでに400名突破でキャンセル待ちだったので、ブログ枠で申し込みました。

で、Zoom の URL 確認しようと開くと

f:id:omron:20211122185247p:plain

450名に拡張されてますね...
通常枠でも受けれたのですが、概ねメモブログ書くからまあ問題なしです。

AWS re:Invent 2020の現状おさらい、AWS2021 主要Updates 第一夜

講師：アマゾン ウェブ サービス ジャパン合同会社　エバンジェリスト 亀田氏

re:Invent

  • 「re:Invent」再発明という意味
    • エンジニア業界ではそんないい意味ではない
    • プロ以外はビジネスに集中しよう
  • 学びの場
    • Work hard, Have fun, and Make history
    • 学んで遊んで歴史を作ろう
  • 5 Keynotes + 1 Have Fun
    • 1つはパートナー向けなので実質は4つ
    • Midnight Madness 復活！
  • re:Play はオフラインのみ
  • 22 Leadership SEssions
    • ここでも新しいサービスが発表される
      • S3 の整合性とかもここで発表された
      • キャッチアップがとにかく大変

Late Night

  • Midnight Madness の代わりに2020年は行われた
  • EC2 Mac Instances 発表
    • EC2 Dedicated Hosts で提供
    • ベアメタルとはちょっと違う
    • Nitro Security Chip など AWS 専用のハードとハイパーバイザーが入ってる
      • Mac mini そのままではない
      • 通常の EC2 と同じように AWS サービスと連携可能になる
      • Nitro I/O カードでの通信
      • Nitro Security Chip をベースとしたシステム管理コントローラー
      • 電源も Mac とは別のもので交換可能になっている
    • Mac 用ソフトのデプロイ環境に使う

KeyNote

  • 今年は Andy Jassy ではない
    • Amazon の CEO になったので
  • 現 AWS CEO の Adam Selipsky が行う
  • マーケットセグメントシェアを言うのは、re:Invent だけ
    • re:Invent 関連以外では、プレゼン禁止
    • マーケット1位だけど、ドルベースだと Alibaba が実は強い
  • 過去のキーワード
    • Builders
    • New Normal
    • Freedom
    • Super Power
    • I want it all and I want it now
      • 機能が似ているサービスはたくさんある
      • 好きなのを使ってもらう
      • Amazon は小売店なので、AWS も同じようにたくさん揃える
    • Transformation
      • Don't stop me now
      • EBC: 企業の経営者に来てもらって話す、専用の場所も備えてる

2020年発表内容

  • EC2 インスタンス
    • 400種類以上
    • 増やすと利益率悪くなるので普通の IT ベンダーは増やさないが AWS は増やす
    • CPU: Intel(Xeon), AMD(EPYC), AWS(Graviton2)
      • Intel
        • M5zn: CPU クロックが一番早い、4.5GHz
        • R5b: EBS だとオーバーヘッドがあるが、これは3倍早い IOPS が出る
        • D3: エフェメラルディスク最大48TB 詰める、内蔵のため壊れるとスケールしてないのでデータは飛ぶ
        • D3en: 336TB、D3の倍の6.2MiB/sスループット、75Gbps のネットワークバンド、東京には無いので日本では要望が少ない？
      • AWS Graviton2: R6g などおしりに g がついているのが Graviton
        • C6gn: 100Gbps を実現するネットワーク特化型
      • AMD
        • G4ad: Graphics の G、GPU
      • Intel Habana Gaudi 発表、DL1 インスタンスとしてリリース、機械学習向けモデル
      • Habana Gaudi のあと Trainium 発表、AWS 版の Habana Gaudi みたいなもの
        • スポンサーの Intel のカニバル商品をすぐにだすのが AWS らしい...
  • ECR Public Repository
    • Docker Hub の AWS 版みたいなもの
    • IAM ベースで制御できる
    • KMS で暗号化可能、スキャン機能付き
  • AWS Lambda
    • Container Image Support for AWS Lambda
      • OCI 準拠のコンテナが動くようになった、最大10GByte のイメージ
      • ECS Fargate よりスケール速度が早いのがメリット
      • ECS Fargate はステート持てるけど、Lambda はステートレスなので注意
        • Fargate と同じコンテナは使えない
    • 課金単位が 1msec
  • ECS Anywhere
    • オンプレサーバーで ECS が動く
    • ECS エージェント必要
      • Systems Manager (SSM Agent)経由でインストール可能
  • EKS
    • EKS Anywhere
    • EKS Distro
      • AWS が OSS として作成
      • EKS から AWS 独自機能を抜いたもの
      • k8s 準拠
      • EKS は9ヶ月でアップデート、EKS Distro はそれより少し長い16ヶ月
  • AWS Proton
    • CFn で作ったマイクロサービスアーキテクチャを管理できる
    • CFn の管理をマイクロサービス用に最適化
      • バージョン管理できるようになる
  • ストレージ
    • gp3 volumes
      • 新世代汎用 SSD ブロックストレージ
      • gb2 がデフォルトだけど gb3 のほうがいい、デメリットほぼ無し
      • 独立したプロビジョニング
        • IOPS のスループットとストレージキャパシティを別々に管理できる
        • gb2 はストレージ容量に応じて IOPS が増える
    • io2 Block Express
      • io2 より4倍高速、低レイテンシー、99.999% の可用性（他の EBS は 99.99%）
      • R5B 専用の SAN ストレージ、EC2 側のパフォーマンスがないと活用できないため
  • RDS
    • Aurora Serverless
      • CPU 利用してないときは返す、ゆえにコールドスタートが遅い
      • Serverless v2 は秒単位でコールドスタートできる、GA はまだ
    • Babelfish for Amazon Aurora PostgreSQL

所感

スタート時点で、130名ちょいで「少ないね...」とぼやきたくなるのもわかる参加率の低さでした。
途中は200名超えたのですが、歩留まり50%割ってましたね。
オンラインとはいえ参加できないと主催者に悪いので参加できることが確定した後に勉強会申し込むのですが、枠がなくて入れないことも多いので予め抑えておきたい気持ちも分かります。
せめてキャンセルはするようにしたい/してほしい。

過去 re:Invent は5回行っており、Keynote を現地で聞いて盛り上がることが多かったのですが、去年はオンラインでの開催だったため記憶があまりない状況です。
Mac インスタンスは衝撃的だったので覚えているのですが、それ以外は「あーそれもあったなぁ」という感じでした。
AWS Proton は良さげに思ったのに使わないまま今に至ってます。
Aurora Serverless は、プロダクトでは使いにくそうなので使わず。

またラスベガスに行って、現地で盛り上がってそのまま色々試したいと思いました。
次はいつ行けるだろう？

Classmethod Showcase Road to 内製化「カルチャーは引き継げるのか？ 〜企業のDevBizOpsへの挑戦〜」 受講メモ

AWS 勉強会

classmethod.jp

絶賛内製化取組中なので、興味あるセッションがたくさんあります。

カルチャーは引き継げるのか？ 〜企業のDevBizOpsへの挑戦〜

講師：アマゾン ウェブ サービス ジャパン合同会社　エバンジェリスト 亀田氏

日本には AWS に数十万のお客様がいる

  • 日本が遅れているわけではない、積極的に使っている
  • CI/CD などの最先端については若干遅れている
  • SI モデル（請負）と相性が悪いのではと思われる

サービス型

  • 固定資産型からサービス型へ
    • 初期投資不要、使用分のみ支払い
    • モノを買うわけではないのでチャレンジしやすい環境
    • カジュアルにものづくりができる

ビルダーズの育成がイノベーションの鍵

  • エンジニアがモノをつくるだけではない
    • 収益やお客様への責任も持つべき
    • 裁量がなければ限界がある
      • 経営陣が考える必要あり
    • 投資コストを最小化できるクラウドの相性がいい

SaaS

  • AWS を使わずに済む方法をまず考える
  • クラウドは高セキュリティ
    • 一般的な企業が作るよりもセキュリティにコストかけている
    • メガバンクも採用している
  • エンジニアのリソースはどこに使うべきかを考える
    • バックオフィス業務は作らずにサービスを使う
  • 88%の企業はクラウドファースト
    • 一方、IT予算はオンプレミスに86%かけている
  • クラウドの利用によるコスト削減

Innovation Fly Wheel

  • 営業とエンジニアを分けるのは古いやりかた
    • お客様からの要望は、サービス開発チームへフィードバックすべき
  • 責任と権限は表裏一体
    • 亀田さんはエバンジェリストとして月1回以上会社へフィードバックする責務がある
    • その代わり自由に日本中出張して講演が許可されている
  • クラウド移行の価値は、インフラ以外が9割以上締める
  • 顧客ニーズを追従する
    • 内製化が鍵

DevOps

  • DevOps は難しい
    • Ops は安定化が大事
    • Dev は追加機能やビジネスを実装
    • Dev と Ops は相反しやすい
  • DevBizOps にする
    • ビジネスとお客数の責任もエンジニアに持ってもらう

マイクロサービスアーキテクチャ

  • Conway の法則
    • 1967年に言われた言葉だけどそのとおりになっている
    • 上長の許可がいる環境ではアジャイル開発なんて不可能
    • 反復的に行われる作業（CI/CD）は組織そのもの
      • 組織の在り方は引き継げない
      • 自動化の仕組みは内部で作り運用する必要がある！
        • ファーストフードのアルバイトはこれができている
        • 社員が仕組みを考え自動化し、アルバイトは動くだけ
  • モノリシックアーキテクチャ
    • 定例会などで協調してみんなでものをつくる
  • マイクロサービスアーキテクチャ
    • チーム単体でビジネス判断できる、権限移譲が必要
      • ビジネス判断できないなら上手く行かない
    • 開発完了後ビジネスのスタート
      • 開発して終わりではなくそこからお客様と会話スタート
      • ビジネスが始まってからちゃんと責任も持つ
    • Two-pizza teams
      • 人数が増えすぎると調整が大変になる
        • 上限は10人程度
      • プロダクトのロードマップ、開発、運用、収益すべてやる
      • 全てのチームに SDE,PM,TPM,SE,SET が存在する
        • 常に人が足りないので外部リソースも必要になったりする

民法

  • 2020年民法改正
    • 瑕疵担保責任 -> 契約不適合責任
    • 納品から1年 -> 事実発覚から1年、時効5年に
  • 作って終わりではない

バイモーダル

分散モノリス

  • フロントエンドとバックエンドをわけても同じビジネスをしている場合などは「分散モノリス」になる
    • EC サイトなどで使われることが多い
    • サービスはマイクロサービスとして別れているけどビジネスが別れてないはコレ
  • ヘッドレスコマース
    • DB は分散したくない
      • センシティブデータの顧客情報は重複管理排除したい
    • フロントエンドは DB を直接見ない
      • 射影（Materialized View）を見る
      • 配送時などは DB から必要データを取り出して利用した後捨てる
    • カスタマージャーニーを起点に考える

所感

いつも素晴らしい話を上手にしてくれる亀田さんのセッションだったので真剣に聞きました。
語彙力崩壊状態ですが、うなずくことしか無い内容ですね。

「AWSの基礎を学ぼう 第六十七回 Amazon Managed Service for Prometheus」 #awsbasics 受講メモ

AWS 勉強会

awsbasics.connpass.com

Grafana とセットで使うことになる Amazon Managed Service for Prometheus です。

セッション

Amazon Managed Service for Prometheus

講師：アマゾン ウェブ サービス ジャパン、シニアエバンジェリスト 亀田氏

クラウドネイティブアーキテクチャ

  • ログを一箇所にまとめて集約できる仕組みがないと大変
    • オンプレミスもまとめたいケースもある
  • メトリックス、ログ、トレースを見るべき

Amazon Managed Service for Prometheus(AMP)

  • OSS のツールキット
  • 簡素な可視化の機能のみもっている
    • Grafana とセットで綺麗に可視化
  • Exporters で Prometheus に蓄積できる
  • AMP
    • TLS 1.2 以上必須
    • CloudTrail でアクティビティを記録
    • Macie と連携で機密情報検知可能
      • アプリでユーザーの IP が保存されている場合に検知するなど

AWS Distro for OpenTelemetry(ADOT)

  • アプリケーションモニタリング用の分散トレーシングとメトリクスを収集するためのオープン API ライブラリ、エージェント
  • EC2, ECS, EKS, Lambda サポート

その他

  • CloudWatch Container Insights, CloudWatch Lambda Insights, CloudWatch Contributor Insights
    • ここで取れるのであれば、Grafana つかわなくていい
  • Insights をつかえば AWS 単体の機能でも可視化はいろいろできる

所感

セミナーの反応も少なめで「ややこしいのでフワッとだけでも理解できるといいです」と言ってたとおり、全然ついてけませんでした。
ハンズオンも共有されてたので、実際に動かしてみないと理解を深めることは難しそうです。

github.com

「AKIBA.AWS ONLINE #07 - データ分析 編-」 #AKIBAAWS 受講メモ

AWS 勉強会

AKIBA.AWS ONLINE #07 - データ分析 編-

dev.classmethod.jp

データ分析したいんだけどどこからやればいいものか...ということで受講しました。

セッション

サーバーレスなデータ分析基盤の紹介

データアナリティクス事業本部 梶原裕さん

  • データの収集と蓄積、分析を行う仕組み
    • 蓄積： Redshift, S3
    • 収集： EC2, Lambda, Glue, StepFunctions
      • EC2 は本質的じゃない部分（メンテとか）がしんどい
      • Glue シンプルでスケーラブルなサーバレスデータ統合基盤、Lambda と違い15分以上処理可能
      • Lambda クロスリージョンで発火できないのは注意、SNS 必要
      • StepFunctions を利用して組み合わせていく
  • アーキテクチャ
    • Lambda -> SNS -> SQS -> Lambda(StepFunctions) -> DynamoDB
      • StepFunctions: S3 -> Glue -> Redshift

Redshift内のデータの活用をAthenaにオフロードしてみた

データアナリティクス事業本部 鈴木那由太さん

  • Redhift に BI ツールがアクセスするケースから変える
    • Redhift から S3 に出力して Athena からアクセスするようにしたい
      • Athena のフェデレーテッド・クエリで、横串検索ができる
      • Athena を BI ツールでアクセス
  • アンロード
    • UNLOAD コマンドにより SQL で Redshift のデータを S3 にエクスポート可能
      • 再アンロードしたくなったらどうする？
        • CLEANPATH オプション利用する
        • PARTITION BY 句と組み合わせると指定したパーティションのみファイル削除
        • WHERE 句を変えるだけで用意に差分変更可能
  • 検索
    • Athena から S3 に対して SQL でクエリを実行
    • データをパーティション分割して、列指向データ・フォーマットにして、コスト改善できる
      • どうやってパーティション分割する？
        • Athena 側で計算、パーティション射影
          • テーブルにパーティションキーのルールやフォーマットを設定して Athena で計算
          • 日付型： 日付の範囲とフォーマットを定義して値を日付として解釈
          • 列挙型： 列挙のメンバーを定義し値を解釈
          • 挿入型： クエリの WHERE 句で単一の値を指定
        • Glue データカタログに登録参照する
  • まとめ

S3にあるデータをAthenaのクエリで取得してLambda ( Pandas ) で加工してみた

データアナリティクス事業本部 笠原宏さん

  • Athena クエリでデータ取得
    • スキーマ定義で Glue Data Catalog が利用できる
  • Athena を利用するケース
    • Athena をつかって S3 内の大量のデータから抽出したい
    • パーティション化してフィアル格納
    • 複数ファイルに分散されている一部利用
  • S3 にある Parguet データを Athena クエリで取得
    • Athena クエリ実行結果を Lambda で取得
      • Lambda の Pandas データフレームに加工できれば Pandas を操作してデータ加工できる
  • AWS Data Wrangler が便利

所感

想像以上に理解できませんでした😇
Glue 使いたいなーと思ってるだけで、触ってないのでちゃんとわかってない。
Redshift も知ってるだけで操作したこと無い。
とりあえず、キーワードだけ拾っといてそれぞれを調査実装復習しないと進展なさそうです。

「JAWS-UG SRE支部 #1」 #jawsug_sre 受講メモ

AWS 勉強会

jawsug-sre.connpass.com

SRE ってなんやねん...という知識で参加しました。

セッション

SREのプラクティスにAWSで取り組むときに悩んでいること

Yuki Andoさん

www.slideshare.net

SRE とは

  • Site Reliability Engineering
  • ソフトウェアエンジニアリングでサービス運用を改善する方法論(from google)
    • 技術だけじゃなく組織・コミュ・文化な側面まで
  • 信頼性とスピードのバランスをとる考え方
    • 信頼性こそプロダクトの基本

SRE がエンジニアリングである理由

  • 顧客体験から SLI/SLO を決める
    • SLO に SRE が駆動される
      • SLO: サービスレベル目標
      • SLI: サービスレベル指標
      • CUJ: クリティカルユーザージャーニー
  • モデル化して定量分析して改善する

SRE on AWS の難しさ

  • AWS のサービスが多い
    • アップデートで最適解が変わっていく
    • サービスの状況ニーズ時期によって判断
  • SLI/SLO の実装をする場合
    • SLI の仕様を決めて実装
    • SLO ダッシュボード、アラートを実装する

Site Reliability Engineering on AWS

Yukitaka Ohmuraさん

SRE が実現すること

  • SREs: Site Reliability Engineer
    • 信頼性などをエンジニアリングで改善することが仕事
    • やるべき作業が先にあるのではない
  • SREs の信条
    • エンジニアリングに対する継続的な注力の保証
    • SLO を下回ることなく変更の速度の最大化
    • モニタリング、緊急対応、変更管理
    • 需要予測、キャパシティプランニング
  • SREs at Amazon
    • サービスチームの中に Systems Development Engineer という職種がある
      • 開発プロセスや運用課題をソフトウェアで解決
      • 横串でプラットフォームだけを担当するものではない
      • SREs の信条と同じ
  • 開発と運用の壁は無い
    • you build it, you run it.
    • 開発者も日々の運用に入る
    • DevOps で Project ではなく Product にフォーカス
  • Amazon のサービス運用
    • すべてをサービスチームが担当する
      • 顧客ヒアリング、プロダクトデザイン、KPI...
    • Two Pizza Team
      • ソフトウェアで解決
      • Self-service Tools を作る便利なツールはサービスにする
        • AWS もそのひとつ

SRE とは？

  • SRE だけが全てではない
  • SRE は Google の考え方
    • Amazon は Two Pizza Team
    • 開発と SREs が同じチーム
    • 唯一の正解はない
    • 組織によって違う
  • SREs チームと開発チームを分けるケース
    • Google はインフラとサービス開発が別れている
    • Error Budget が必要になる、これも一つのやり方

SRE を AWS で実現するには

  • AWS ベストプラクティス
    • AWS Well-Architected Framework
      • 運用上の優秀性、セキュリティ、信頼性、パフォーマンス
  • アーキテクチャによる高信頼性確保のナレッジ
    • Amazon Builder's Library
      • Amazon がソフトウェアをどのように構築して運用しているかを知る
      • 例）静的安定性：依存関係が壊れてもシステム全体は動作する
  • 言葉は大事
    • 運用課題をエンジニアリングで解決することに SRE と名前がついた
      • 必要だけで注目されなかった領域にフォーカスがあたった
    • でも言葉に縛られない
      • 目的はサービスを利用するお客様へ価値を提供すること
  • 運用が始まったら開発を止めてでも改善に注力する
    • プロダクトマネージャーの判断にはなる

いにしえの日系大企業の情シスに勃興したSREチームの奮闘記

御田 稔さん

speakerdeck.com

  • DX の波が来て SRE チームができた
  • 基幹系情報を集約して API で社内提供するシステム構築
  • オンプレや AWS との連携課題
    • Direct Connect
    • VPC 接続方式フロー整備
  • 社内運用系機能がレガシー
    • AWS 運用管 PF を構築
    • Datadog 環境準備
  • 委託管理に慣れた社員の技術スキル
    • AWS 商用システム保守作業の内製化推進
  • 苦労ポイント
    • AWS の標準化と統制
    • AWS の予算計画
    • SRE が解るようにジョブディスクリプションを作成

オンラインの技術カンファレンスを安定稼働させるための取り組み

inductorさん

speakerdeck.com

  • コロナ禍でのミートアップ運営側
    • Zoom 便利
    • 配信機材準備大変
    • 懇親会、質問大変
  • カンファレンス
  • 改善したこと
    • AWS の改善は極力入れる
      • 仕事じゃないので好きに実験
  • まとめ
    • SRE を実践できる環境は少ない
    • サービスのフェーズに合わせて取り組む
    • 多様性大事
    • SRE チーム作って満足しない
      • サービスが正しく動くように

SRE on AWSのことはじめ〜スタートアップ協業におけるビジネスに寄り添ったSLO定義・計測に関する取り組み事例〜

Masaya ARAIさん

speakerdeck.com

SLO 定義計測に関する事例

  • 金融系スタートアップ
    • セキュリティ PCIDSS 準拠必須
    • 信頼性が大事なので「機能」として位置づけ
  • 最初に SLO を構築
    • 重要なふるまいの定義
      • 可用性（稼働率）、レイテンシ遵守率
        • どんな根拠で値をつくる？
        • AWS や関連システムのサービスレベルの前提を考察
        • プロダクトに対する利用者の期待を考察
          • ビジネス領域の重要度を俯瞰
    • 計測と評価
  • SLO を主軸として SRE の文化を醸成するのが本番

weblioはSREチームの0→1フェーズにどのようにAWSを取り入れているのか

paprika-mahさん

  • 最優先はセキュリティ
    • CMS を守るために WAF 導入
      • 特定検索で403が出た
      • Cookie内容によってはエラー
        • WAF のチューニングが必要
  • 次はモニタリング
  • SRE の準備
    • 可観測性、回復力、疎結合、管理力
    • クラウドネイティブにするため 12FactorApp な作りへ
  • SRE を取り入れる
    • 即効性がない、文化や組織を変える必要あり

所感

送迎で懇親会をすぐに離脱することになったのが残念。
SRE とはを丁寧に色々な角度で知ることができるいい勉強会でした。

プロダクトの信頼性を高めるために、計測して指標を作成しエンジニアリングで解決しようというもの。
SRE は、小さい組織だとなんでも屋さんのスーパーマンがこなすしかなく、大きな組織だとサイロ化せずに開発と一緒に進めるのが大変そうな印象です。
知見を持った仲間を増やしていきたいなぁ。

「AWSの基礎を学ぼう 第六十六回 Amazon Managed Service for Grafana」 #awsbasics 受講メモ

AWS 勉強会

awsbasics.connpass.com

OSS Grafana の AWS マネージド版となる Amazon Managed Service for Grafana です。

セッション

Amazon Managed Service for Grafana

講師：アマゾン ウェブ サービス ジャパン、シニアエバンジェリスト 亀田氏

Grafana

  • 分析、インタラクティブな可視化できる OSS
  • プラグインを介して機能を拡張
  • CloudWatch は送り込まれて表示
    • Grafana は取りに行くので、データを持つわけではない

Data sources

開始方法

  • AWS SSO or SAML 認証
    • ID/PWD 認証は無い
  • Datasource を登録
    • IAM は Sigv4 で自動登録される
  • Dashboard 作成
    • テンプレートで GUI 作成
    • AWS サービス向けは内蔵

所感

CloudWatchLogs で困ってなければ、使う必要もないかなという印象を受けました。
オンプレ等違う環境で、すでに Grafana を使っており、AWS 環境でも統一したいときとかが一つのユースケースでしょうか？

CloudWatch よりも「カッコいい」が一つのウリみたいです。
確かに今どきなダークベースのテーマで表示できておしゃれですので、それだけを目当てに使うのもありですね。