SRE NEXT 2024@Abema Tower 登壇資料まとめ
SRE NEXTに行ってきました SRE NEXT 2024に参加してきました！資料のまとめ集です。 メルカリさん、ランチごちそうさまです🍞 SRE NEXT 2024タイムスケジュール ※ユーザ名は敬称略です。 Day1 工学としてのSRE再訪 @yuuk1t 登壇者紹介リンク: https://x.com/yuuk1t/status/1819631327219798137 組織的なインシデント対応を目指して〜成熟度評価と改善のステップ〜 @nari_ex 登壇者紹介リンク: https://x.com/nari_ex/status/1819640326585516199 巨大インフラ産業で戦うSRE @m_norii 登壇者紹介リンク: https://x.com/m_norii/status/1819631055290486797 アンドパッドのマルチプロダクト戦略を支えるSRE
【2024年夏】ブラウザ拡張機能開発を加速するフレームワーク・ツール3選をコードベース付きで紹介！
本記事では、ブラウザ拡張機能開発を加速させる、個人的に注目な3つの拡張機能開発フレームワーク・ツール（WXT、Plasmo、Extension.js）を紹介します。 サンプル拡張機能の実装を通して、それぞれの特徴、セットアップ方法、実際の開発フローを見ていきます。お好みの拡張機能開発ツールが見つかれば嬉しいです。 各フレームワーク・ツールの紹介 WXT WXTは、Viteベースのブラウザ拡張フレームワークです。次のような特徴を持っています（トップページから抜粋）。 クロスブラウザ対応 Chrome、Firefox、Edge、Safari、その他Chromiumベースのブラウザ Manifest V2、V3の両方に対応 開発モードでのHMRと、開発用ブラウザの自動起動 内部的にChrome Launcher等を使用 ファイルベースのエントリーポイントでマニフェストを自動生成 Nuxt風の自動
オープンなAmazon Cognitoエミュレーター "Magnito" のご紹介
はじめに こんにちは。かる(@caru)です！ 大学生として勉強する傍ら、日々フロントエンドエンジニアを目指して活動しています。今回は、私がコミッターとして参加しているMagnitoというOSSプロジェクトについて紹介します。 皆さんは、AWSのCognitoというサービスを知っていますか？ スマホアプリからWebアプリまで、多くのアプリケーションで認証・認可の機能は不可欠です。その中でも、Amazon Cognitoは多くの開発者に利用されている認証・認可サービスの一つです。この記事では、Cognitoを使う際の課題と、Magnitoがそれにどう対応するかを紹介します。 Amazon Cognitoとは Amazon Cognitoは、Amazon Web Serviceが提供するユーザー認証、認可、およびユーザー管理を簡単にするためのサービスです。これにより、アプリケーションにユーザー
pnpm 9.5 でリリースされた Catalogs 機能を使ってモノレポ内の依存パッケージのバージョンを揃える
Catalogs を使うモチベーション Catalogs のメリットについては、ドキュメントではざっくり以下の3点が挙げられています。 単一バージョンを維持できることで、パッケージの重複によるバグの発生を防ぐ pnpm-workspace.yml を編集するだけで依存関係のアップグレードが完了する 依存関係アップグレード時に package.json を編集しなくてよくなり、git でのコンフリクトを避けられる 筆者の環境では特に1つ目の、「パッケージの重複によるバグを防ぐ」というのが大きなモチベーションとなりました。 モノレポと共通パッケージとパッケージ重複 筆者の環境では一部の Web Frontend もモノレポで運用しており、そのなかで一部の共通実装はモノレポ内パッケージとして切り出されています。以下は架空の例ですが、おおまかにこのような構造となっています。 たとえば各 webap
Rails の非同期処理を Sidekiq から Cloud Tasks にリプレイスして Cloud Run のコストが6分の1になった話
成果 最終的に、Cloud Run のコストが$6/day前後から$1/day前後に！ ちなみに、Cloud Tasks は1ヶ月あたり最初の100万回のオペレーションまで無料なので余裕で収まっています。 モチベーション 今回リプレイスを検討したシステムは軽量な非同期処理が大半で、もともと絶対に Sidekiq でないと困るということが少なかった Sidekiq は Redis をポーリングしてジョブを取得する方式なので、Cloud Run で実行するには min-instances を1以上にしなければいけない 何もジョブがない状態が続いてインスタンスが0になると起こしてくれる人がいないので... 絶対に Sidekiq でないと困らないなら Cloud Tasksにして、非同期処理がない時は寝ていても良いようにしたい => コストダウン！ Pub/Sub との比較検討もしましたが今回は
マツコの知らない LINE ログインの世界
Ubie プロダクトプラットフォーム所属の nerocrux です。今回は Ubie において、 LINE ログインを成功させるために工夫したことをいくつか紹介したいと思います。 面白いこともすごいこともやってないし、対象読者もよくわかりませんが、興味があったら読んでみてください。 はじめに 症状検索エンジン「ユビー」について Ubie では、症状検索エンジン「ユビー」（以下、ユビーと呼ぶ）という一般ユーザー向けのサービスを展開しています。ユーザーが簡単な質問を回答することで、関連する病名や、適切な受診先情報を得ることができるサービスとなっています。 ユビーは Web ブラウザ経由で利用されることが多いですが、iOS / Android のネイティブアプリも提供しています。 ユーザーがユビーを利用する際に、ユビーのアカウントを作成することで、一貫性のある問診・受診・受診後のフォローアップ体
GitHub の削除されたリポジトリや非公開のリポジトリに誰でもアクセスできるの？
こんなタイトルの記事を見かけました。 GitHubの削除されたリポジトリや非公開のリポジトリに誰でもアクセスできてしまうのは仕様通り 元の記事はこちらです。 Anyone can Access Deleted and Private Repository Data on GitHub もしもこれらが本当にタイトル通りだとしたらさすがに大事件なので、検証してみました。 要約 Accessing Deleted Fork Data フォークのコミットは、フォークを削除したあとも、フォーク元のパブリックリポジトリ経由で参照できる。 Accessing Deleted Repo Data パブリックリポジトリのコミットは、フォークが作成されていたら、パブリックリポジトリを削除したあとも、フォーク経由で参照できる。 Accessing Private Repo Data プライベートリポジトリのフォ
そのデータ、いつになったら削除しますか
きっかけ Omiaiで保管されていた運転免許等の本人確認画像が流出した件で触発されました。 本人確認のためだけに使うなら、確認後は不要なはずなので即破棄という運用でも問題ないはず。 ただ実際には内部事情の都合で、スマートに破棄できないのが実情だったのではないでしょうか。 証跡のために残されるデータ こういった実質もう使わなくなったけど、後でユーザーから依頼だったり事件があったときのために証拠を提出したいから残してほしいという要件はままあります。 特に昨今はクラウドネイティブなインフラが増えてきたのもあって、保存できるデータ量にほぼ制限がなくなってきました。 それに伴って画像ファイルのような少々重いデータでも、証跡としてずっと残していてほしいというクライアントは少なくないです。 個人的な印象ではログのローテーションの間隔もかなり長くとりたがる傾向にありますね。 またデータベースのレコード削除
3rd Party Cookie 廃止の方針変更など : Cybozu Frontend Weekly (2024-07-23号)
3rd Party Cookie 廃止の方針変更など : Cybozu Frontend Weekly (2024-07-23号) こんにちは！サイボウズ株式会社 フロントエンドエキスパートチームの @mugi_uno です。 はじめに サイボウズ社内では毎週火曜日に Frontend Weekly と題し「一週間の間にあったフロントエンドニュースを共有する会」を開催しています。 今回は、2024 年 7 月 23 日 の Frontend Weekly で取り上げた記事や話題を紹介します。 取り上げた記事・話題 Temporal を取り巻く仕様を整理する ECMAScript Stage 3 の Temporal に関する発表資料です。仕様そのものの整理や、タイムゾーン・カレンダーのサポート、Intl との関係性について解説されています。 Fastly が開発者向けの無料プランを提供開始
マルチAWSアカウント環境のセキュリティって無理ゲーじゃね？
対象読者 様々なプロダクトへ AWS アカウントや環境を提供する SRE / CCoE チームを想定しています。 マルチAWSアカウント環境 SRE / CCoE は各プロダクトが安全かつ便利に AWS を利用できるよう、AWS アカウントの設定・払い出しや周辺コンポーネントの提供（踏み台・ID管理・ログ収集 etc...）を行います。 個別プロダクトの基盤設計や構築は行いません。 私の担当案件では 100 以上の AWS アカウントを提供しています。これでも多いとは言えず、例えば NTT ドコモでは 2,000 以上の AWS アカウントを管理[1]しているそうです。 セキュリティ対応方針 セキュリティグループの全開放や S3 バケットのパブリック公開など、AWS リソースの不適切な設定についての対応を考えます。 ゲート型 IAM ポリシーやサービスコントロールポリシー (SCP) で
自分が管理する全 OSS の Issue や Pull Request を 1 つの GitHub Project に集約
2024-07-24 追記: 本記事の続きで、開発組織でのソフトウェア開発の Issue や PR を自動で適切な GitHub Project に割り当てていく方法についても書きました。 https://zenn.dev/shunsuke_suzuki/articles/manage-enterprise-issue-pr-by-project タイトルの通り、自分が管理する全 OSS の Issue や Pull Request (以下 PR) を 1 つの GitHub Project に集約した話を紹介します。 自分は様々な OSS をメンテしており、様々なリポジトリで作られる GitHub Issues や PR を日々ハンドリングする必要があります。 しかしこれだけリポジトリの数が増えると一つ一つリポジトリを巡回してハンドリングしていくのは困難です。 ユーザーによって issu
RFC 9116 から読み解く正しい security.txt の書き方
security.txt は非常にシンプルな text/plain ファイルであり、既成のものをコピペして .well-known/security.txt として配置するだけであれば、ものの数分で対応できることでしょう。 また、自動で作成してくれる Web アプリも公式で用意されています。 ですが、例えば「Preferred-Languages に優先順位はあるの？」、「攻撃者によって security.txt が改ざんされたらどうなるの？」といったことは気にならないでしょうか。 私はとても気になります。 というわけで、早速 RFC9116 を読んでいきましょう。 tl;dr はこちら Abstract Section 1 は割愛すると書きましたが、概要にだけは最初に触れておきます。security.txt は第三者であるセキュリティリサーチャーのために書かれたものであり、この RFC
エンジニアを10年以上やって視力2.0を保つ秘訣
前書き エンジニアを始めて１４年、独立して９年経つ。 この仕事を始めた時に「さすがに眼が悪くなるかな」と思ったが、４０過ぎていまだに裸眼1.5／2.0だ。（昨年はどっちも2.0。） ↓今年の検査結果(右列が昨年) これはなんなら、始めた時より眼が良くなっている。（始めたころは1.2／1.5だった。） 先日知人のエンジニアと話していると、彼は２００人規模のエンジニアを抱える会社でリーダーをしているが「メガネをしてないエンジニアなんて会った事ない」と驚かれた。 実はそこに秘訣があるのでシェアしたい。 ちなみに妻はこの方法で片目だけだが0.9 → 1.2になった。 結論 「平行法を覚えろ」 これに尽きる。 遺伝の影響か ちなみに自分の親族・家族は実は須らく眼が悪い。 逸話的にも、若くして眼鏡を掛けていた父が、母をお見合いで最初に見た時に、「こいつも眼鏡掛けてる。」「もし子どもが出来ても全員目が悪
AWS RDS/Auroraでモニタリング＆チューニングを始めるための資料11選
これはなに ども、レバテック開発部のもりたです。 もりたはデータベースが好きなんですが、最近は特にAWS RDS/Auroraでのモニタリングとパフォーマンスチューニングについて興味があります。ただ、これらのうちモニタリングは扱っている話題が若干ローレベルであまりピンとこず、またチューニングもどこから手をつければいいのかわかりませんでした。 この記事では、もりたがモニタリング＆チューニングを学習する上で役に立った書籍やWeb上の資料をロードマップ形式で紹介していきます。対象読者はDBのモニタリングとチューニングをやりたいけどどこから手をつければいいか分かんないなとなっている人、ゴールはそんな人がモニタリング＆チューニングの第一歩を踏み出せることです。 スコープ 今回扱うもの、扱わないものは以下の通りです。 扱う モニタリング＆チューニングの概要 モニタリングの前提知識 チューニングの前提知
Terramateを使えばIaCは豊かになれるのか?
序論 先日LinkedInで面白そうなIaCツールを紹介してもらいました。 マネージドサービス版はまだクローズドベータで一般利用できませんでしたが、GitHubにCLI版がオープンソースとして公開されておりました。 一見、Terraformの実行を代行するTerragrunt[1]のようなラッパーツールかと思いましたが、Terramateは単なるラッパーツールではなくオーケストレーションツールとしてIaC開発を楽にしてくれるさまざまな機能が提供されていましたので、Terramateを使ったIaC開発について紹介いたします。 対象読者 複数のIaCツールの管理に苦労している人 (後述のハンズオンのため)Terraformの基礎知識がある人 Terramateについて 創業者のブログを見ると2022年5月にリリースされた比較的新しいGo製の開発ツールのようです。 ドキュメントではTerrama
Terramateで始めるIaC CI/CDパイプライン
序論 先日IaCをオーケストレーションしてくれるツール、Terramateについて紹介しました。 この時はクイックスタートということでnullリソースを使ってTerramateの動作確認程度のハンズオンを実施しました。 今回は複数のStateファイルで分割され、CI/CDパイプラインの処理に時間がかかるようになったTerraformリソースをTerramateを活用して、変更差分があった場所のみ検知してapplyを実行するCI/CDパイプラインの構築について紹介いたします。 対象読者 Terramateを使ったCI/CDパイプラインの構築に興味がある人 Terraform(OpenTofu)の基礎知識がある人 GitHub Actionsの基礎知識がある人 IaC(Terraform)導入後の課題についておさらい Terramateの概要については私の記事や本家ドキュメントを読んでもらえま
tfcmtのいい感じのテンプレート
それぞれが折りたたまれていてコメント全体がコンパクト リソースの数が増えてもコメントが縦へ長くなることはありません。 開けばこのように表示されます。 危険な操作(削除・更新)があったときにわかりやすい 削除や更新があった場合は画像のようにその部分だけは折りたたまず表示してくれます。 日本語なので読みやすい(日本人にとって) いい感じのコメントにするための tfcmt.yml 基本的に公式ドキュメントのDefault Configurationを日本語化して上記の修正を加えただけです。 なので、もとの英語表記がいいとか、特定の機能だけ取り込みたい、という方は以下と公式のDefault Configurationでdiffを取ると特定の機能だけ取り込みやすいと思います。 embedded_var_names: [] templates: plan_title: "## {{if eq .Exi
GitHub Actionsの脅威検知ツール tracee-action を触ってみる
はじめに こんにちは、セキュリティエンジニアのJJ (yuasa)です。今回はGitHub Actionsのワークフローにおける脅威検知ツールであるtracee-actionを触り、検知ルールの書き方について見ていきます。なお、tracee-actionは2024年7月時点で本番環境での利用は想定されていない点にご注意ください。 This project is not production ready. We are experimenting with it to test and demostrate Tracee capabilities. tracee-action tracee-actionはTraceeを用いてGitHub Actionsのワークフローにおける脅威を検知します。TraceeはeBPFを用いてLinuxランタイム上でのシステムコールを検出することができるツールです
多店舗展開するジムの会員入退室管理を材料費数万円で実現し、２４時間営業にした話
ジムの会員管理システムを作った僕に「エニタイムフィットネスみたいなことがしたい」とジムを家族経営するお客さんから相談された。 「えっ！？会員管理を作ったついでにエニタイムフィットネスみたいな仕組みをやりたい！？予算は無い！？不正防止のため、入退室時の写真も撮りたい？！ログもとりたい！？」 さすが筋トレに明け暮れてるオーナーさんの要望はマッチョだと思った。 普通にやれば電子錠の仕組みや工事やらで一店舗あたり数百万から一千万掛かるような仕組みだろう。 そんな予算無いみたいだし、既存の店舗をそんな大々的に工事もできない。そもそも自分にそんな工事の知識もない。 結果Raspberrypiを使い、それを一店舗予算10万円代で実現、会員カードを他店舗と共有した24時間営業にできた。 その詳しい技術的な内訳を共有する。 （なお執筆時点では２０２４年だが、これ自体は５年前、２０１９年の仕事である。） 前提
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
巷の Terraform Module に違和感を感じたので納得できるものを作ってみた【AWS VPC編】
