omuronの備忘録

個人的な備忘録

「AWS個人検証アカウントどう運用してる？ランチ共有会」 #jawsug_tokyo 受講メモ

AWS 勉強会

AWS個人検証アカウントどう運用してる？ランチ共有会

jawsug.connpass.com

セッション

LT① 個人検証アカウントでも最低限設定したいプラクティス ～私の環境のご紹介～

木澤 朋隆さん

speakerdeck.com

  • AWS Organizations 立ち上げ
    • 本番と検証アカウント分離
    • 不要リージョンの無効化
    • アカウント作るときはGMailの+でエイリアスアドレス使う
    • SSO でログイン設定
  • セキュリティ設定
    • ClaudTrail で証跡監視
    • Config で履歴
    • GuardDuty で保護と脅威検知
    • Security Hub でアラートの一元的な表示と管理、チェック自動化
  • Budgets は有効にしよう

個人でも Organizations 使うのは有用とわかってるけどなかなか大変ですね。
本番環境で Organizations 検証するのが難しいから個人でこそやるべき項目でもある。

LT② そのNAT Gateway要りますか？

大元 隆志さん

  • NAT Gateway は月に7,000円ぐらいかかる
  • NAT Gateway の代替手段
    • Public だけ使う？
    • (Netskope社員特権で)ZTNA（ゼロトラスト ネットワーク アクセス）化しよう
      • EC2 をパブリックに置いてそちらを経由してPrivateにアクセスすることで ZTNA を実現

NAT インスタンス立てる方法ですね。
NATG は気軽に起動停止をEventBridgeでできないのがつらいところ。

LT③ どんな感じでアカウント運用をやってるかを軽く共有

藤原 涼馬さん

speakerdeck.com

  • マルチアカウントでしか検証できないもの
    • アカウント単位でしか設定できない S3 のパブリックアクセス設定
    • クロスアカウント設定
  • Organizations で管理する
    • 用途に合わせて作って終わったら捨てる
    • IAM Identity Center で一括ユーザー管理
    • よく使うものは IaC でテンプレ化して使い回す

やっぱり Organizations でアカウント作って不要になったら捨てるのが楽でいいですね。

LT④ 全削除ツールaws-nukeをカスタマイズしてみた

石塚 詩織さん

  • aws-nuke
    • 一括削除できるツール
    • 削除対象のカスタマイズが柔軟にできる
  • nuke-config.yaml
    • 必須設定
      • 対象リージョン
      • 絶対消したくないアカウント
        • 無いときは dummy を入れる必要あり
      • 削除対象アカウント
    • オプション
      • リソース名、タグ指定、削除対象、削除保護の無効化

デフォルトの動作が dry run なのがいい。

「まるクラ勉強会 ONLINE #1」 #まるクラ勉強会 受講メモ

AWS 勉強会

まるクラ勉強会 ONLINE #1

classmethod.connpass.com

セッション

20分で大体わかる！AWS Glue Data Qualityによるデータ品質検査

niinoさん

  • Glue にデータ品質検査を伴う Glue Data Quality が追加された
    • ETL Jobs や DataCatalog で使える新機能
    • AWS の OSS の Deequ を使ってる
    • 定義は DQDL(Data Quality Definition Language)利用
    • Helper からルールを追加、もしくは自動でルールをレコメンドもできる
      • CW や SNS で通知できる
  • 設定場所
    • Glue Data Catalog のテーブル内で設定
    • ETL Job の中に組み込み

このあたり Q が勝手にやってくれる世界がきそう。
いやむしろ来てほしい。LLMに丸投げしたい。

人人人〜データを作り、使い、示唆を得る〜

ほりもとさん

  • データ分析関連ツール
  • データアセットのドキュメントを残すのが大事
  • データ分析ツールはちゃんと使う
  • dbt
    • SQL知ってればデータ変換が容易に可能
    • データパイプライン化可能
  • Data Mart層から部署やチームに渡せるのが理想
    • Raw Data層 -> Staging層 -> Data Warehouse層 -> Data Mart層
    • Data Warehouse まではエンジニアリングのお仕事
    • 層分けは組織によって変わっていい

おじさんだから「人人人」が分からぬ...

Tableauでやってみるデータ可視化やBIについて

投埜さん

はるか昔に Tableau 触ったのを思い出しました。
本格的に使うことはせず QuickSight にしたので、Tableau と比べれないんだけど QuickSight は Tableau を追っかけてることだけは何となく知ってる。

「早くすることだけが正解じゃない - イケてる組織を作るための開発生産性とは？」#開発生産性_findy 受講メモ

勉強会

早くすることだけが正解じゃない - イケてる組織を作るための開発生産性とは？

developer-productivity-engineering.connpass.com

セッション

LT①：『開発生産性を計測し、開発組織の当たり前基準を上げる』

株式会社グロービス VP of Engineering 大沼 和也さん

  • 1チームのスクラムマスターをしていた
    • 複数チームのスクラムマスターへ
    • CI/CD整備、QA入れて週１デプロイ
    • ビッグバンリリースやめてデプロイを日常へ
  • 開発組織も指標化して改善したいので Four Key Metrics を使ってみた
    • 「正しい積み上げ」をするための仕組みを作りたい

「（金融の）業界だから無理」という言い訳は存在しない。 デプロイ頻度が高くて困ることもない。

デプロイ頻度は一番測りやすい指標ですね。

LT②：『より早く良いものを多くのお客様に使ってもらうために。勘ではなくデータで判断する改善プロセス作り』

弥生株式会社 CTO 佐々木 淳志さん

speakerdeck.com

  • 成果を考えるのになにをミッション・ビジョンにしていたかに立ち返る
  • どうやって可視化する？
    • 考えるより実際のお客様に使ってもらう
    • 改善回すには定量化必要
    • 早くサイクル回す
      • ゴールまでの道筋を短くする
      • ゴールは動くので観測必要
  • お客様の利益を上げるのが目的なので見かけのスピードを求めるものではない

目的はたしかにそうなので、意味のないスピードを求めるのは不要ではありますが、まずはスピードにこだわるのもありかなー。

「JAWS-UG東京 ランチタイムLT会 #7」 #jawsug_tokyo 受講メモ

AWS 勉強会

JAWS-UG東京 ランチタイムLT会 #7

jawsug.connpass.com

アーカイブ

www.youtube.com

セッション

LT① DB管理をお客様に任せてみた

居石 峻寛さん

speakerdeck.com

  • テナントごとに DB を管理してもらう構成
    • アプリレイヤー（VPC に ALB + EKS）は共通
    • テナントごとに VPC + Aurora 別れている
  • 接続方法
  • Private Link を選択
    • CIDR 重複気にしなくていい
    • SG でアクセス制御
    • Private ホストゾーンでドメイン付与可能
    • EC2プロクシ利用する必要があった

お客様ごとに物理的（という表現は微妙だけど）にDBを分けて安全性を確保してるんですね。
この要件満たすのは大変そうだ。

LT② AWS認定全冠から始まるクラウドジャーニー

SimStaさん

speakerdeck.com

  • クラウド認定資格はTOEICみたいなもの
  • 全冠しても継続的な勉強必要
  • AWS認定はAWSを理解するための近道

イベントで専用ラウンジやノベルティもらえるのは嬉しいですよね。
資格を取るモチベーションは知りたいところ。

LT③ やさしいTerraform Module入門

よなさん（クラスメソッド株式会社）

speakerdeck.com

  • root
    • main.tf: どのようなモジュールがあるか受け渡し、パスを記載
    • variables.tf: 変数を定義

どのように Terrfaform のファイルが参照しているかを図示していた理解しやすかった。
資料を参考にして Terraform も勉強してある程度かけるようにならないと、AWS はいいんだけど Cloudflare とか他のSaaSがつらいし。

LT④ 結婚式WEB招待状をAWSリソースでサクッと自作した話

髙橋 透さん（NRIネットコム）

speakerdeck.com

  • 自分の結婚式の招待状をWebで解決
  • Route 53 でドメイン取得
    • .link が安くて $5
  • ACM で証明書
  • Route 53 で CloudFront CNAME レコード登録
  • S3 バケットを作って HTML アップロード
  • CloudFront -> S3 紐づけ設定

静的サイトだとこれが最適解ですね。
メンテ不要でほっとける。

LT⑤ AWS DirectConneectパートナー選定時のチェックポイント

山本 泰士さん（NTTデータ）

speakerdeck.com

  • DirectConneect
    • AWS とオンプレミスを接続してくれるパートナー業者の選定が必要

専門家なのでわかりやすいお話でした。
複数業者が入るのでどこが責任を持つかわかりやすい...がアプリ屋さんしていると活用することが自分はなかなかなさそう。

「JAWS-UG朝会 #53」 #jawsug_asa 受講メモ

AWS 勉強会

JAWS-UG朝会 #53

jawsug-asa.connpass.com

登壇は3ヶ月待ち！

セッション

セッション① IPv4からIPv6へ切り替えをしてみよう

アイディーエス 小寺加奈子さん

speakerdeck.com

  • パブリックなIPv4への課金が2/1から始まる
    • IPv4アドレスの枯渇対策
    • 1つのパブリックなIPv4ごとに$3.65/月かかる
  • IPv4:ユニキャスト（1:1）、ブロードキャスト（1:全て）、マルチキャスト（1:n）
  • IPv6:ユニキャスト、マルチキャスト、エニーキャスト（近い人と通信）
  • VPC
    • VPC IP Address Manager の新機能 "Public IP Insights" で使っている Public IP の個数が把握可能
    • VPC を IPv6 オンリーで作ることができる

IPv6って口頭でアドレスとかCIDRとか言うの不可能じゃないですか？

セッション② EC2 Instance Connectを図解してみた

クラスメソッド おのやんさん

  • EC2 Instance Connect
    • EC2 に ssh でアクセスする機能だが、ssh キーを自身で共有管理する必要なし
    • マネジメントコンソールや cli 経由でアクセスできる
      • Instance Connect で接続時に ssh の鍵ペアが作られる
      • 公開鍵が EC2 インスタンスへ送信されて Meta Data に保存される
      • キーペアは自動で削除される
    • EC2 Instance Connect はサービスなので CloudTrail で追跡可能
      • SendSSHPublicKey イベントが残る
  • EC2 Instance Connect Endpoint
    • Public IP アドレスがないプライベートなインスタンスに対して SSH/RDP できるサービス
    • OpenTunnelイベントが残る

ssm との違いがわかって助かりました。

LT① Codeシリーズで作るTerraformのCI/CDパイプライン

IRET 檜山 準さん

  • CodeCommit を採用して AWS 内でセキュアに管理
    • CodeCommit は開発環境の AWS
    • main へのマージでクロスアカウントの商用環境にデプロイ

LT② Amazon Kendraの動画ファイル検索機能を実装してみた

陳暁璐さん

LT③ CloudShellで入門するAWS CLIv2のすゝめ

坂之上 大輝さん

  • なぜ AWS CLI
    • スクリプト化が容易
    • マネジメントコンソールのUI/UXに課題が多い
  • 自動プロンプトを有効化する
    • aws --cli-auto-promp
  • jq 活用
    • . [] | と select 憶えれば基本的に使える

jq 難しい。LLMの出番です。

所感

IPv4有料化が迫っている。 単価安いしと思ってたけど結構な値段になりそうだから真面目に考えないと。

EC2 Instance Connect の解説は面白かった。 ssm と使い分けを考えよう。

「SRE立ち上げてどうなった？最新のコア技術とSRE事情 Lunch LT」 #SRE_findy 受講メモ

勉強会 SRE

SRE立ち上げてどうなった？最新のコア技術とSRE事情 Lunch LT

findy.connpass.com

セッション

LT①「SRE、このへんで苦戦しがちじゃないですか？」

株式会社X-Tech5 馬場俊彰さん

speakerdeck.com

  • SREおさらい
    • モチベーション：Opsがどんどん増えていかないようにしたい
    • DevOpsを実現する一つの手法
  • SREエンタープライズロードマップ
  • 言外の前提条件の認識不足
    • ステークホルダーと対話して認識合わせが大事
    • 会社全体として信頼性に価値を置いているか
  • 変化を定着させる困難さ
    • 大人の変化は難しい
  • 取り組みの事業価値・商業的価値の言語化不足
    • 一度やめてみるのも手
  • まとめ
    • 始めるより続けるのが難しい
    • 理論、理性、情熱大事
    • わかってもらうには一度燃やすのも手

SRE 流行ってるから始めるじゃ失敗しがちですよね。
片手までやるのも難しいし情熱を持って引っ張る人や専任者がいないとうまくいかない。

LT②「SRE を立ち上げた4ヶ月後の世界」

株式会社Magic Moment 木村 竜介さん

speakerdeck.com

  • SRE立ち上げの経緯
    • エラーが毎週増えていくし、顧客も増えていく
    • 手動で対応するためロードマップへの影響が出る
    • ポストモーテムで反省してSREチーム発足へ
      • システムの定点チェックができてなくて状態変化に気がつけてなかった
  • SRE立ち上げ後にやったこと
    • SRE活動からSREチームに変更
    • Core SRE（全体） と Embedded SRE
    • SRE活動を整理整頓
      • バラバラだった活動を「顧客が本当に必要だったもの」にトリアージ
    • 見える化と監視
      • Datadog でアラート整備
      • Datadog APM 導入してマイクロサービス間のトレースを可視化

専任化するのとあわせてオブザーバビリティちゃんとしよう。

LT③「SREチームの立ち上げから5年間とこれから（仮）」

株式会社サイバーエージェント（株式会社サムザップ出向中） Yoshioka Suguru （吉岡 賢）さん

  • インフラチームが SRE チームをかねてすべてのプロダクトをみていた
    • インフラチームはサーバの整備と保守と思われるので名前を SRE チームに変更
  • SRE チームの行動指針を作成
    • UXファースト
    • オープンなチームであれ
    • その技術はイケているか？
    • 1人プレイ禁止
    • むちゃをしない
    • 感謝されるチームであれ
  • 技術および業務の標準化
    • ドキュメントの場所や内容を規定
    • ログの場所や内容を規定
  • 最後にSREチームを解散して各プロジェクトにSREメンバーが所属するように変更
    • Embedded SRE として活動を進める
    • プロジェクト内に閉じこもりがちになるのは課題
  • 課題
    • 文化の属人化：組織じゃなくて人に依存している
    • Observability：Telemetryの標準化とカスタマイズが難しい

SREチームを解散するのがゴールというアプローチが面白い。
プロダクトチーム入れてよりよく実践していくのか。

LT④「カンファレンスから見る SRE トレンド」

株式会社 Topotal Ryota Yoshikawaさん

speakerdeck.com

  • カンファレンス
    • 日本：SRE Next
    • 海外：SRECon

Incident Response が US では盛り上がってるとのこと。

所感

SREチームを作ってきた実際の事例がたくさん聞けて参考になりました。
まずはSREチームをちゃんと立ち上げて横串的に活動しつつ、重要なプロダクトではEmbedded SREも入れていくのが良さそうかな。

2023年の振り返り

年末と言うことで、2023年のアウトプットを振り返ってみます。

  • 登壇12回
  • ブログ65記事（社内ブログも含む）
  • 勉強会170回以上

でした。
登壇を中心に振り返ってみます。

今年の登壇

Amazon Forecast を使って売上予測をしてみた

speakerdeck.com

JAWS-UG朝会 での登壇です。
Amazon Forecast を試してみたくて試しました。
実際に使って見るところまではできてませんが、簡単に使えることはわかりました。

Stripe / Okta Customer Identity Cloud(旧Auth0) の採用に至った理由　〜モリサワの SaaS 戦略〜

speakerdeck.com

Stripe x Okta 共催セミナーでの登壇です。
原宿の Stripe オフィスに呼んでいただき登壇しました。
企業に呼んでもらえるのは嬉しいですね。
事例も書いていただけました。

stripe.com

3種の神器でサブスクサービスを構築した話

speakerdeck.com

JP_Stripes 大阪での登壇です。
小島さんつながりで CircleCI もちょっといれて話しました。

Okta Customer Identity Cloud (旧Auth0) の 採用に至った理由 〜モリサワの SaaS 戦略〜

speakerdeck.com

Okta 社のオンラインイベントです。
Stripe オフィスでのイベントがきっかけで、こちらにも登壇することになりました。

未経験からデータ基盤を1年で作ってみた

speakerdeck.com

ビヨンド勉強会での登壇です。
会社から近い難波でのイベントだったので、初参加なのに登壇してみました。

老舗企業が開発組織カルチャーの刷新を行い SaaS 戦略に切り替えた話

speakerdeck.com

AWS Dev Day 2023 Tokyo の登壇です。
初の AWS 公式イベントでの登壇でした。
スペシャルトラックに SaaS があったので、記念に申し込んでみたら、まさかの採択でした。
とてもいい経験になりました。

DevOpsの推進からのFour Keysの計測へ

speakerdeck.com

Findy のイベントです。
Findy Team+ を導入したので、その内容に沿ったイベントがあったので申し込んで登壇することができました。
その後、事例にもしていただけました。

blog.findy-team.io

Amazon SES のバウンス率が急上昇 〜Amazon SES を止めてしまった日〜

speakerdeck.com

nakanoshima.dev での登壇です。
この回から、運営が AWSJ ではない方々がされてました。
失敗系は受けるのか、今年公開した資料で一番 View 数が多い資料になります。

Serverless で運用を楽にしたい

speakerdeck.com

JAWS-UG 大阪での登壇です。
前回の nakanoshima.dev のときに、登壇に誘っていただけました。
サーバーレス座談会だったのでサーバーレスの話をしました。

なぜ老舗企業がOktaでDXを実現できたのか？

speakerdeck.com

Okta 社の関西拠点設立イベントに呼んでいただきました。
関西の企業や大学など、普段とは違ったスピーカーたちでした。

SESからSendGridに変更したけど移行で問題が出た話

speakerdeck.com

JAWS-UG朝会 での登壇です。
朝会はテーマが絞られてないし、オンラインなので登壇の申込みのハードルが低いですが、人気は高いようで2ヶ月待ちでの登壇でした。
今も3ヶ月先ぐらいまで埋まってるようです。

開発生産性向上に向けた定量的なチーム目標設定のメリット

zenn.dev

Findy 社の「開発生産性カンファレンス ~After Findy Team+ Award 2023~」でパネルディスカッションをしました パネルディスカッションは初めてだったのでいい経験になりました。

さいごに

昨年 AWS を使った大きなリリースをしたので JAWS の登壇が多かったのですが、今年は企業主催のイベントに多く出させていただきました。
仕事も AWS メインのインフラエンジニア業務から、テックリードや組織運営側の比重が大きくなったのも影響がありそうです。

来年も引き続きイベントに呼んでいただけるように頑張りたいと思います。 今年も一年ありがとうございました。