技術系フィードから毎時取り込んでいる、まだ誰も拾っていない記事です。ジャンルで絞って探せます。ログインすると、気になったものをその場でブックマークできます。
AWS・GCP、コンテナ、SRE
NTTドコモビジネス株式会社（以下、ドコモビジネス）は、日本最大級のネットワーク展示会である「Interop Tokyo 2026（会場：幕張メッセ、会期：2026年6月10日〜12日）」において構築されるShowNetにContributorとして参加し、docomo business SIGN™を活用したモバイル回線・セキュリティ・データ利活用に関する取り組みを行いました。 本記事では、ShowNet管理網へのセキュアなリモートアクセス環境の構築、脅威検知・フローログを活用したセキュリティ機能の評価、およびMEC/SDPFクラウドサーバーやクラウドサービスと連携したテレメトリデータの収集・
こんにちは！バクラク事業部Platform Engineering部SREグループのtaddy( id:sadayoshi_tada )です。 バクラクではオブジェクトストレージとしてAmazon S3（以降、S3と呼称します）を使用しています。保存するオブジェクトの増加にともなってS3のコストが上昇したことを契機に、アクセスパターンにもとづいてオブジェクトのストレージクラスを見直しました。その過程で使ったS3のストレージクラス分析について、概要と設定手順、分析結果からストレージクラスの変更を行った後のコスト推移を本記事で紹介します。 ストレージクラス分析の概要 ストレージクラス分析の設定手順
1. はじめに こんにちは。プラットフォームエンジニアリングチームに所属する小泉（@naotoko_）です。 本記事は、同チームの徳富（@yannKazu1）が執筆した「消えるランナーの観測基盤をどう選んだか — Datadog・マネージド・OSS を料金体系で比べて Loki + Prometheus に決めた話」の本番環境への導入編です。EKS Auto Mode でホストしている Self-hosted Runner の監視基盤に Grafana・Prometheus・Loki・Alloy を導入した際にハマったポイントと解決策を、各コンポーネントごとにお伝えします。 Grafana・P
こんにちは、tatsuo48/横山達男です。 2026年7月10日（金）〜7月11日（土）に開催されたSRE NEXT 2026に、ドリンクスポンサー・登壇・運営スタッフの立場として参加してきました。 本記事では、イベント全体のふりかえりと、社内メンバーの登壇・参加者の感想をメインにお届けします。そして最後にはSRE NEXT 2027に向けた嬉しいお知らせもあります。 SRE NEXT 2026 概要 SRE NEXTは、信頼性に関するプラクティスに深い関心を持つエンジニアのためのコミュニティベースのカンファレンスです。 sre-next.dev 開催日時: 2026年7月10日（金）〜7月
IIJ ネットワークサービス事業本部 セキュリティ本部 セキュリティ情報統括室の桃井 康成（ももい やすなり）が、このたび一般社団法人ICT-ISACより功労賞を受賞しました。 ICT-ISACとは ...
こんにちは。 サービスプラットフォーム部 SRE チームの谷合です。普段はメガネ集めと、キャンプギア収集、毎日のビールを楽しみながら生きています。 2026年7月10日〜11日開催のSRE NEXT 2026 に登壇してきました。 「Inclusive SRE」のテーマの通り、様々なロールの方や経験者の方が多く参加しておりました。Devサイドの方との共同発表や、デザインの視点からCUJを考えるといったセッションがあり、「Inclusive SRE」を体現した発表だったなと感銘を受けました。 弊社のおすすめセッションは以下の記事にまとめていますので、本記事と併せてご覧ください。 tech.and
はじめに こんにちは！初めまして、クラウドワークスのSREチームの中村です。 半年前の2026年2月にクラウドワークスへ入社しました。 チームのメンバーからSRE NEXT 2026が開かれると教えてもらい、参加を決めました。 個人的に設定していた目的は3つあります。 自社と他社の差分を知ること SRE界隈での自分の輪を広げること 日々のタスクを解決するアイデアを持ち帰ること 上記3点を胸に会場へ向かいました。
こんにちは。FinOpsチームTech Leadの吉澤です。 アンドパッドは、7/10(金)〜11(土)開催のSRE NEXT 2026にLOGOスポンサーとして協賛しました*1。現地にはSRE/DBRE/CRE/FinOpsチームの幅広いメンバーが参加しました。 この記事では、現地参加したメンバーによるおすすめセッションをご紹介します。アーカイブ動画もこれから公開されると思いますので、これからSRE NEXT 2026の内容を追う方は、ぜひご参考ください。 アンドパッドのメンバーによる発表 おすすめセッション SREチーム 千明のおすすめ Terraform共通モジュールをチーム横断で“変え
はじめに この記事は SRE 連載です。 前月の記事ははてなブログに Amazon CloudFront SaaS Manager を導入した話でした。 前月に引き続き id:hagihala です。 はてなのとある Perl で実装された大規模サービス (以下「対象サービス」) は、Amazon ECS Fargate 上で運用しています。コスト最適化を検討するにあたり「Graviton (arm64) に移行すればコストが下がるのでは」という仮説のもと検討を始めたのですが、対象サービスのワークロードで実際に速くなるのか、信頼できるデータが必要でした。また昨年9月に Amazon ECS M
はじめに こんにちは。プラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 GitHub Actions のセルフホストランナーを運用していると、「あのジョブのログ、後から見たいんだけど……」という場面、けっこうありますよね。普段は気にしないんですが、いざ調査となると地味に困る。しかもランナーは ephemeral（ジョブが終わると Pod が即削除される）なので、見たい頃にはログが残っていない、という状態でした。 今回は、この「消えるランナー」のログとメトリクスを観測できるようにした話です。ただ、構築手順そのものよりも、 「Datadog・マネージド・OSS
はじめに IT 基盤部 第二グループの無津呂です。 私たちのチームがインフラ運用を担っているプロダクトにおいて、ジョブキューシステムを Solid Queue に移行しています。 Solid Queue のパフォーマンス特性に関する検証と考察 | BLOG - DeNA Engineering はじめに ゲームサービス事業本部の三軒家です。 社内のとある Ruby on Rails プロダクトにて、ジョブキューシステムのバックエンドを Solid Queue に移行するプロジェクトを推進しています。 この記事では、Solid Queue への移行に際して実施した負荷試験の様子と、その結果として
IoTの活用が広がる中で、本格的にビジネス活用に取り組む企業が増えています。 しかし、いざ構築・運用を始めると、遠隔デバイスの管理やセキュリティ確保に課題を感じるケースも多いのではないでしょうか。本記事では、NTTドコモビジネスが提供するIoT向けネットワークプラットフォーム「docomo business SIGN™」の機能の中から、運用に役立つ「デバイスアクセス」と「フローコレクター」を実際に試した様子をご紹介します。 はじめに docomo business SIGN™とは docomo business SIGN™におけるデバイスアクセスとフローコレクター デバイスアクセス フローコレ
こんにちは、 id:sezemi です。 次期サッカー日本代表監督の推しは本田圭佑さんです。 「そろそろいける気がする！」を見計らった采配に期待です。 さて、アンドパッドでは、技術やプロダクト開発、組織に関するさまざまなカンファレンス・イベントでの登壇、開催や会場提供などを行っています。 今月もイベント情報をまとめてお知らせします。 ぜひご参加ください !! なお、開催状況により、満員となってしまっていたり、すでに受付を終了している場合がございます。 1. スポンサー情報 | SRE NEXT 2026 開催日時 : 2026年7月10日(金) ~ 11日(土) 会場 : TOC有明 主催 :
こんにちは、SREの@babarotです。 10Xでは GitHub Organization のリソースを Terraform で管理しています。メンバーの追加・削除、チーム構成、78リポジトリの設定（Repository Ruleset、アクセス権、GitHub Environments）など、可能な限りすべてコードで定義してPull Requestベースで変更・運用しています。 この仕組みで目指しているのは「SREだけが管理する」のではなく「誰でも安全に変更できるセルフサービス」です。メンバーの追加はtfvarsに1行足してPRを出すだけ、リポジトリの設定変更は各チームが自分でPRを出せ
こんにちは、コネヒト株式会社で働く北島と申します。社内ではしょうぽんと呼ばれています。 最近弊社ではwebエンジニアもインフラ周りのことを吸収していこう、という機運が高まっています。 そこで今回はECSのコスト削減を実施した事例を紹介します。 x86_64（amd64）から ARM64（Graviton）へ 0. TL;DR ママリのメインAPIのECSワークロード（Fargate + EC2）をx86_64 からARM64（Graviton）へ移行 狙いはコスト削減。AWS公称でGraviton版Fargateはx86比約20%安（price-performanceは最大40%改善） 併せて
こんにちは。SREグループの木村です。 SREグループでは、インフラの構成管理、監視、障害対応、開発チームへの支援を担っています。 手順は定まっていても状況ごとに判断がいる業務が多く、その判断基準はメンバーの経験に委ねられていました。 この基準をClaude CodeのSkillとして書き出し、チームでレビューできるようにしました。 チケット運用とダッシュボード確認の2つの事例と、Skillの定期実行基盤を紹介します。
はじめに こんにちは、バックエンドエンジニアの小笠原（@yukineko_819）です。 Checkout Reliabilityチームに所属し、負荷試験環境の構築や購入ロジックの最適化など、購入体験の信頼性向上に向けた取り組みをしています。 今回は、「どのショップでも、いつでも安定して購入できる」という購入体験を守るために、購入時のクレジットカード決済へ流量制御（以降、レートリミッタ）を導入した話をご紹介したいと思います。とくに、特定のショップに購入が集中しても、ほかのショップでは決済ができる状態にする ために、アクセス集中の影響をできる限り抑え、全体の購入可用性を平準化する設計をどう考えた
こんにちは。 サービスプラットフォーム部 SRE チームの谷合です。 普段はメガネやキャンプギア収集と、毎日のビールを楽しみに生きています。 前回は入社後意識的にやっていたボール拾いからトイルの改善に発展させた話を書きました。 tech.andpad.co.jp 今回はタイトルの通り、新規サービスの構成をアーリーフェーズで見直し、前例踏襲ではなく最適な構成に移行した取り組みをご紹介します。 序文 リリースの改善 ネットワーク構成の最適化 さいごに We are hiring! 序文 サービスが産声を上げた直後から数ヶ月のフェーズ。それは、システムが実際にユーザーに使われ始め、初期のアーキテクチ
はじめに さくらインターネット サービス統括本部 技術戦略室の山本です。 Terraform for さくらのクラウドでは、新しい世代となるTerraform Provider v3を正式にリリースしています。 v3では […]
はじめに こんにちは。Merpay の Payment & Customer Platform で会計システムを開発・運用する Accounting チームで Backend Engineer をしている @me […]
自画自賛している図 ALBログ転送Lambdaを、17個まとめて葬りました こんにちは。コネヒトでソフトウェアエンジニアをしているしょうぽんです。 今回は、社内のLT会でも話す予定の「ALBのアクセスログをElasticsearchに転送しているLambdaを、17個まとめて葬ってきた話」をブログ用に書き直してみます。タイトルだけ聞くとちょっと物騒ですが、ちゃんと供養（統合・整理）してきましたのでご安心ください。 この記事で一番お伝えしたいのは、実は技術的な中身そのものではありません。「誰かに頼まれたわけでもない地味な負債返済を、エンジニアが自分の判断で進められて、しかもそれが社内でちゃんと賞
こんにちは、IT 基盤部の西崎です。主に DeNA がグローバルに展開するゲームのインフラ管理を担当しています。 今回は MySQL のバージョンアップによって社内で利用しているツールで障害が発生し、その調査をした時のことをまとめてみます。細かい話になりますが、大規模に MySQL を使っている環境ならではの経験を紹介できると思います。 この調査自体は数年前に行ったものなので、この後の対応などについても追って記事にできればと考えています。 何が起こったのか DeNA では MHA という MySQL の高可用性ツールを利用しています。
「さくらのクラウド」の「シンプル監視」は、2016年のリリース当初から存在しているサービスですが、実はクラウドファースト時代と足並みをそろえて進化しています。この記事では、シンプル監視の主な機能と基本的な設定方法を解説し […]
コンテナ化を進めたいものの、Kubernetesの運用負荷は高い。一方で、一般的なPaaSではネットワークやセキュリティ要件を満たせない。AppRunは、そうした「コンテナを使いたいが、運用は極力したくない」システム向け […]
はじめに IT基盤部第一グループの大田です。 私はインフラエンジニアとして日々の運用を担当する一方で、ここ一年ほどはチームの長期施策の進捗管理にも関わるようになりました。自分が直接担当する施策について、複数の関係者と調整しながら課題を前に進めることには慣れていましたが、そうではない案件について、PM(プロジェクトマネージャー）として間接的に完了まで見届ける仕事にはまだ不慣れでした。 そこで私は、PM業務、その中でも特に進捗確認の部分をAIで楽にできないかと考えました。複数のプロジェクトが並行して進んでいると、どの施策が順調で、どこにテコ入れのフォローが必要なのかなどを把握し続けることが手間にな
インフラ勉強会とは インフラ勉強会は、コミュニケーションツール「Discord」のサーバ上に作られた、オンラインの勉強会コミュニティです。Discordアカウントとインターネットがあれば、どこからでも・誰でも（※1）無料 […]
Terraform（テラフォーム）は、インフラ構成をコードで管理し、構築や変更を効率化するIaC（Infrastructure as Code）ツールです。 さくらのナレッジでは全2回にわたり、さくらのクラウド向けTer […]
Terraform（テラフォーム）は、インフラ構成をコードで管理し、構築や変更を効率化するIaC（Infrastructure as Code）ツールです。 本記事から全2回にわたり、さくらのクラウド向けTerrafor […]
はじめに こんにちは。インフラ・ストリーミングチームの小河です。 本記事では GitHub リポジトリにおける master への意図しないマージを防ぐために行った取り組みについて紹介します。 私たちのチームでは、いわゆる Git-flow に少し似たブランチ運用ルールを設けています。 このブランチ運用ルールと GitHub の Pull Request との仕様の組み合わせで master ブランチへの意図しないマージが起きやすい状態になっていました。 今回実際に事故が発生してしまったため、GitHub Actions を活用して再発防止の取り組みを行いました。 なぜ意図しないマージは起こっ