物騒な世の中です。皆様お気をつけください。 3行でまとめ 自作の OSS、fujiwara/apprun-cli のマルウェア入り偽物を作られて GitHub で公開されました 偽物には大量の新規アカウントがスターを付けていたため、検索でオリジナルのものより上位に表示される状態でした GitHub に通報したところ、偽物を作ったアカウントはbanされたようです 経緯 2024年末に、さくらのAppRun用デプロイツール apprun-cli という OSS を公開しました。 github.com 2025年2月10日 12時過ぎのこと、謎の人物が X で apprun-cli を宣伝しているのを見つけました。 どう見ても自分の物と同じ(コピー)なのですが、妙にスターが多い。リポジトリをのぞいてみると、fork ではなくコードがすべて commit 履歴を引き継がない状態でコピーされ、スター
はじめに IT 本部 IT 基盤部第一グループの山本です。 AWS Aurora のマネージドバックアップのコストの以下の記述についてコスト計算が直感的にわかりづらかったので、実際にコストを確認してみました。 Aurora provides unlimited free storage for all snapshots that lie within the automated backup retention period. After a manual snapshot is outside the retention period, it's billed per GB-month. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-storage-backup.html 結論 自動バックアップの
SRE Kaigi 2025で発表した資料です
SRE Kaigi 2025でお話した資料です。
スライドの中で紹介しているURL↓ ・ Engineering Career Paths at Big Tech and High-Gro…
突然ですが皆様は、稼働済みサービスのDBからテーブルカラムを削除されたりすること、ありますでしょうか？ 基本的に削除はまずやらないのではと思います。えっやらないの？ と思われた方もいらっしゃるかもしれませんが、きっとこの記事を読めばなぜ多くの方がカラム削除を避けるのかわかることでしょう。 とはいえ、そうして使わないカラムがテーブルに溜まっていくとやがて新規加入メンバーがコードにキャッチアップする妨げとなるレベルにまで溜まってきたりします。いつかは大掃除のときがくるわけです。DBは寿命長いですからね。そうしたときに実際どのような手順でカラムを削除するのか見ていきましょう。エムスリーエンジニアリンググループUnit1（製薬プロモーション）・Unit9（治験臨床研究支援）チームエンジニアの三浦 [記事一覧 ]が、最近実際にやった作業から知見をお届けします。 長いので3行で 考え方 1. そのカ
この投稿はBASEアドベントカレンダー2024の21日目の記事です。 はじめに SRE Group でエンジニア？をしている@basemsです。 まだ入社して5ヶ月の若輩者です。 「エンジニア？」という表現は、私の現状は技術そのものではなくチーム運営だったり業務改善といった方向に注力しているので、まだ「BASEのエンジニアです！」と自信を持って名乗る程ではないという心理の表れです。 本記事はエンジニアとしてというより、過去の経験からくるプロジェクトマネジメントの面が強い内容になっております。 この記事って何 私自身、BASE以前に何社か渡り歩いていますが、PJ進行においてエンジニアと非エンジニア間の軋轢だったり衝突は大なり小なり発生しない方が稀だと感じています。（部署の違うエンジニア間でもあったりする） が、その改善方法や心構えのブログ記事とかはネット上に存在はしてますが、体系立てて学ぶよ
この記事は terraform Advent Calendar 2024 の 9 日目の記事です。 Terraform だけでアプリケーションのバックエンド・フロントエンド・インフラをつくったので紹介します。 つくったもの 利用技術 バックエンド フロントエンド インフラ Full-Stack Terraform まとめ つくったもの 画像を表示するだけのサンプルアプリケーションです。 Gallery リポジトリはこちら。 使用言語 利用技術 バックエンド バックエンドの実装には次世代のモダン AltJS である JS.tf を使用しています。 JS.tf を使うと HCL で JavaScript プログラムを記述することができます。 data "js_function_call" "hello_world" { caller = "console" function = "log" a
本記事は、CyberAgent Group SRE Advent Calendar 2024の5日目の記事です。 メディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断
前記事 AWS ECS Fargate Autoscaling の実戦的な基礎知識 の続きというか派生的なところで、こんな監視項目がこんな理由でえぇんちゃうん、という基礎知識的なお話です。 当ブログでは『監視よければ全てヨシ！』という格言を推していますので、監視の仕込みをサボっている人は今からでも頑張っていきましょう。 はじめに もともと書くつもりでいた本タイトルは、公式からこのドキュメントが出たことで、ゴミ箱行きかと思いました。 推奨アラーム – Amazon CloudWatch > Amazon ECS んが、まぁ所詮はドキュメントということで、ここではもう少し実戦に寄り添う形でまとめていければと思います。 あったら嬉しい監視項目をカテゴリごとに整理しつつ、その理由やら補足情報によって、楽しく監視できるようにしていきたいところです。合わせて読みたいところとしては、この辺もどうぞ。 ミ
カミナシのエンジニアリング組織では、チームメンバーの AWS アカウント環境への定常的なアクセス権限として「センシティブな情報を除いた全リソースへの ReadOnly Access」を付与しており、一方で書き込み権限については必要に応じてメンバーが一時的に権限を獲得できる仕組みとシステムを開発し、運用を行っています。 本記事では、そういった仕組みを開発するに至った経緯や仕様、そしてこれを数ヶ月ほど運用した結果と今後の展望について紹介します。 このシステムは『ハマヤン』という名前で呼ばれていますが、あまねくユーザーに愛される素敵な名称であり、Sec Eng チーム内でも大人気です。開発者が濱野さんだからハマヤンにしたのでは？と社内で言われることがありますが、真相は不明です。 ハマヤンを開発した理由 ハマヤン開発前の2022年頃、カミナシではソフトウェアエンジニア全員が Administrat
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事は クラウドワークスグループ Advent Calendar 2024 シリーズ1 の 2日目の記事です。 あるときはTerraform職人、またあるときはお豆腐職人の @minamijoyo です。 2023年8月HashiCorpはこれまでMPL2のOSSライセンスで公開していた主要製品をBSL(Business Source License)に変更することを発表し、Terraformはv1.6.0からOSSではなくなりました。このライセンス変更を受けて、OSS版のTerraformを求める人たちで、MPL2時点の
はじめに 表題のようなCLIツール aws-iam-policy-sim を書きました。 github.com 使い方 Statement フィールドに、以下のようなオブジェクトの配列が入っている、というJSONファイルを用意しましょう。 Action フィールドにアクション名もしくはその配列 Resource フィールドにリソースもしくはその配列 たとえば以下の通りです。うっすらお気づきの方もいると思いますが、実はポリシードキュメントのJSONがそのまま使えます。 { "Statement": [ { "Action": [ "s3:PutObject", "s3:GetObject", "s3:GetObjectTagging", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::example-bucket/*" ] }, { "Act
SREチームの長田です。 今回はAWSのVPC(Virtual Private Network)内で作業する時の話です。 VPC内で作業したい VPC内で作業したいこと、ありますよね。 環境構築中の動作確認とか、不具合・障害調査のための定形外作業とか、メンテナンスためのイレギュラーな作業とか。 定常的に行うほどではないですが、AWSでVPCに絡んだサービスを使用しているなら、VPC内での作業は少なからずあると思います。 VPC内に閉じたリソースにアクセスする場合は、当然ですがVPC内からアクセスする必要があります。 VPC外からアクセスするための経路を用意すればそれも可能ですが、アプリケーションが使っている経路とは異なる経路を使うことになるため、 不具合調査時の再現確認などでは余計な要素となることがあります。 VPC内からの操作は、AWSであればCloudShellで VPC環境を作るのが
MySQL 8.0 の速いバイナリを作ってみよう
念を押しておきますが、このブログの「内容は個人の考えであって、所属組織とは方針が異なる」と考えてください。 前のエントリでは、MySQL 8.0は、clangのPGO+LTOでビルドしないと本来の性能が出ない。ということを証明しました。その後、PGO+LTOといってもプロファイリングをどうしたらいいのかと、デスクトップマシンの空き時間でひたすらビルドとtpcc(ramfs)を繰り返した結果、興味深いことがわかりました。 tpccのようなある程度複雑なベンチマークは、 ベンチマークそのもの（この場合tpcc）をプロファイリングするよりも、 mysql-testのスクリプトを組み合わせて工夫したほうが性能が出る ということです。（少なくとも私の環境で、ではですが） つまり、 ビルドしてテストスクリプトが流せる環境であれば、総合的に最適に近いバイナリが生成できるということです。誰でもビルドできま
Autoscaling については過去に何度か書いているのですが、今回は ECS Fargate について少し掘り下げつつ整理してみたいと思います。 仕組みとしては難しくはなく、わりと雑な理解度でも動くっちゃ動くとはいえ、リソースとしての重要度は高い箇所であり、正しく理解するとより関連箇所の最適化が見込めるところでもあります。 概要 ECS は on EC2 で動かすと、インスタンスとタスクの二段階での Autoscaling になるところが、Fargate だとタスクのみで考えられる簡素さが強みです。 ECS Service のタスク群に対して、特定の条件（主に平均CPU使用率）を満たした時にタスク数を自動的に増減することで、負荷対策とコスト削減という目的を達成しつつ、運用者が基本は放置できることになります。 ただ、それだけの理解では浅すぎるので、増減における詳細やリスクなどについて把握
SREチームの長田です。 皆さんは操作するAWSアカウントを取り違えたことはありますか？ 私はあります。 カヤックのSREは複数のプロダクトを担当することも多く、 ひとつのプロダクトでも環境(本番、ステージング、開発、etc.)ごとにAWSアカウントを分ける場合があり、 扱わなければならないAWSアカウントが多くなる傾向にあります *1。 今回はうっかり別のアカウントのリソースを削除してしまったーといったオペレーションミスを減らすために個人的に行っている、 「気をつける」以外の対策を紹介します。 間違いに気づくための対策 対象のアカウントが操作の対象として正しいかどうかは、結局は操作している本人にしか分かりません *2。 そのため、「アカウント取り違え自体をなくす」のではなく、 「アカウントを取り違えていることに気づきやすくする」ための対策をしています。 AWSコンソール用の対策 AWSコ
BASE も Aurora MySQL v3 となりました SRE Groupの ngsw です。 2024/10/14〜10/15の深夜メンテナンスにて、BASEで利用しているAmazon Aurora MySQLのバージョンは、v2系からv3系となりました。 アップグレードの前提条件で大きなつまずきがありましたが、gh-ost を利用することで、乗り越えることができました。 この記事では当該アップグレードの中で gh-ost をどのように利用し、どういう恩恵を受けたかについて述べていきます。 おさらい : v3 対応しないとどうなるの？ Aurora MySQL v2は標準サポート終了が発表されており、v3への移行を終えていないDBクラスターには自動的に有償の延長サポートが適用される流れです。 Amazon RDS 延長サポートの使用 - Amazon Aurora 2024/10/3
こんにちは Diverse developer blogです。今回はプロジェクトの構想から完了まで、1年半ほどかけて行った「PerlとDebianの更新プロジェクト」を振り返ります。 なぜやったのか？ 弊社のYYCは20年以上稼働しているサービス（SNS, マッチング, ライブ配信）です。ユーザーの要望に応えるため、機能開発を優先してきたことで開発環境の改善が遅れていました。 特にバックエンドの開発言語（Perl 5.8）と、コンテナOS（CentOS）のアップデートが遅れており、今後の機能開発やセキュリティ対応に課題が生じていました。 そのため、プロジェクトの目標は「開発言語とコンテナOSをLTS（long-term support）バージョンまで更新する」ことにしました。そして、課題を一つ一つ段階的に解決して、ついに目標を達成しました。現在のYYCのバックエンドは、最新のPerl5.4
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
