2021年の年初に発生したSlackの大規模障害について、Slackが障害の原因をまとめたレポートを公開しました。年末年始の長期休暇明けの「仕事始め」が、障害の根本的な原因だったようです。 Slack’s Outage on January 4th 2021 - Slack Engineering https://slack.engineering/slacks-outage-on-january-4th-2021/ 太平洋標準時の2021年1月4日、Slackに大規模なアクセス障害が発生。この障害は1月4日午前6時ごろから始まり、午前7時から午前8時30分頃まで、Slackにアクセスできない状況が続きました。 Status Site https://status.slack.com/2021-01/9ecc1bc75347b6d1 2021年1月4日、Slackのインフラチームはサービス

しばたです。 世の開発者の中にはいわゆるdotfilesと呼ばれる設定ファイル群をGitHubなどのSCMで管理している方がいらっしゃいます。この方式に倣いAWS CodeCommitをAWS CloudShellの構成管理に使えないかとなんとなく思ったので試してみることにしました。 ちなみにこのやり方がCloudShellの管理に最適かどうかはわかりません... それを検証するためにまずは試してみようというのがこの記事の趣旨となります。 Why CodeCommit? AWS CloudShellは$HOME配下は永続的に保持されるものの、120日アクセスが無いと自動で削除されるため永久保存ではありません。 このためCloudShellで使うデータに対して決して消えないことを求める場合は何らかの外部ストレージを必要とします。 単純に外部ストレージが必要なだけであればS3でも構いませんし、

これは、私が若…くはないけどピカピカのAWS1年生だった、数年前のお話です。 何をやらかしたのか やらかし前の状態 本番運用しているWebアプリケーションの裏側に、EC2インスタンス3台でクラスタを組んだ某データストア製品を使用していました。データはクラスタ内でレプリケーションされており、1台がダウンしただけならクラスタは稼働を継続できます。2台がダウンするとクラスタ全体が機能しなくなります。 ある日、3台のうち1台で障害が発生してインスタンスへ疎通できない状態になりました。この時点ではクラスタは正常に応答しており、あと1台ダウンしない限りはサービスに影響が出ない状態でした。 まず、ダウンしてしまったインスタンスを再起動して復旧させようとしました。ところがEC2マネジメントコンソールから再起動、停止を選択しても障害中のインスタンスは反応しません。そして私は間違いを犯します。 やらかしたこと

本日のアップデートで Amazon S3 Storage Lens がリリースされました。 Amazon S3 Storage Lens delivers organization-wide visibility into object storage usage and activity trends S3 Storage Lens とは S3 Storage Lens はオブジェクトストレージの使用状況とアクティビティの傾向を可視化し、コスト効率化、データ保護に関するベストプラクティスに向けた推奨事項が提供されます。また AWS Organizations と連携することで AWS Organizations 内のアカウント全体のストレージ使用状況、アクティビティを単一ビューで管理できます。 無料でも使える！ 標準メトリクスのみの場合、S3 Storage Lens は無料で利用できま

秋のスポットインスタンス祭り ～ そろそろクラウドネイティブなコスト最適化はじめてみませんか？ 発表資料です https://awsj-compute.connpass.com/event/192302/

こんにちは、 IT 基盤部第一グループの山本です。 今回は AWS のセキュリティインシデント通知のエスカレーションの仕組みについて紹介したいと思います。 概要 AWS 上のリソースで不審な動きをしているものが検知された場合、AWS はメールまたはサポートケースによって利用者へ通知を行います。セキュリティグループの設定不備によって EC2 インスタンスに侵入されたり、IAM の credential の漏洩によってリソースに対する操作が不正になされたりした際に送られる Abuse Report がその代表例です。このような不正利用はセキュリティインシデントにつながりうるため、即座に検知し対応する必要があります。 一方、DeNA は数百個の AWS アカウントを管理しているため、これらすべてのアカウントの通知を日々目視で確認することには限界があり、前述の通知を見落としたり初動が遅れたりする可

株式会社ラクスが開催するエンジニア向けのイベント「RAKUS Meetup」。今回は「SaaS新規プロダクトの技術」をテーマに、同社プロダクト「楽楽労務」など、AWS関連のインフラを担当する柏木達仁氏が登壇し、「積極的にAWSサービスと自動化を使ってtoBのSaaSをローンチしたその後」という内容で話をしました。 なぜAWSを多用するのか 柏木達仁氏（以下、柏木）：楽楽労務の担当をしている柏木達仁と申します。今回のテーマは、インフラから「積極的にAWSサービスと自動化を使ってtoBのSaaSをローンチしたその後」というテーマで発表します。よろしくお願いいたします。 自己紹介です。私は2010年に新卒で入社して、SIerだったのですが、パッケージシステムやSaaSに関わっていました。2017年にご縁があってラクスに入社して、インフラ開発部に所属しています。主にblastmailというサービス

Azure Hybrid全体整理！ ~ Azure Hybrid Dayに登場した要素 + αの関係性を整理！ ~

はじめに CTOの川口 (id:dmnlk) です。 5月にオンラインmeetupをさせて頂きその中で「具体的な負荷対策に関しては開発ブログで！」と言っていた件ですが気づいたらもう9月になりかけていました。 コロナ禍においてネットショップ作成サービス「BASE」の利用者様が急増しました。 www.nikkei.com 5 月には 100 万ショップを超えるショップオーナー様にご利用していただいております。 今まで EC 事業を行っていなかった飲食店様や様々な業種の方が利用をはじめていただき、ショップオーナー様も購入者様共に短期の見通しでは想定をしていないアクセスが発生しました。 その途中でシステムとして対応しきれない面もあり、アクセス負荷によるサービスの不安定を招き皆様にはご不便や販売時間を変更していただくお願いなどをしてしまい大変申し訳ありませんでした。 現在では安定しておりますが、その

こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井 亮です。 日本国内においても多くのシステムがクラウド上で稼働していることと思います。 俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。 ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が本格化してきたというのが肌感覚であります。 クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。 クラウド上では出来ること出来ないこと

はじめまして、2020年3月に中途入社したSREチームの @bayashiok です。 今回は入社後、Fargateでサーバレスバッチ基盤を構築した話を書いていきます。 目次 目次 経緯 Fargateを選んだ理由 1. リソースの見積もりがCPU/Memoryだけですむ 2.スケーリングを考えなくて良くなる 3. セキュリティレベルの向上につながり管理負荷が減る 現行システムで発生している問題点の解消 構成 FargateのトリガーとしてRundeckを採用 理由1： バッチ実行が行われる場所でログを見たかった 理由2： ジョブ失敗やSlack通知の仕組み、リトライ方法やジョブ連携などの作り込みを簡単にしたかった ecs-taskとの連携について デプロイ 1. wrapperコンテナのデプロイ 2. バッチのデプロイ Fargateタスク実行について 移行後の総括 よかった点 悪かった

こんにちは。はてなのアプリケーションエンジニアの id:onk です。 最近、若手エンジニアを中心に、いろいろな技術を見つめ直すワーキンググループをやっています。今回は、その中から「デプロイ」の会で発表されたことをまとめました（なお、私は会のとりまとめをやっている非若手です）。 デプロイのライフサイクルの違い Infrastructure Platformでのデプロイ Application Runtime Platformでのデプロイ Applicationsのデプロイ デプロイ方式はどのように変化してきたか In place から Blue/Green へ Immutable Infrastructure という考え方 オートスケールへの対応 push 型デプロイと pull 型デプロイ コンテナによるデプロイの現況 コントロールプレーンによって何が変わったか ECS におけるデプロイ

技術部 SRE グループの mozamimy です。 クックパッドでは、 SRE が中心となって、サービスを動かす基盤の大部分である AWS のコスト最適化を組織的に取り組んでいるため、今回はそれについてご紹介します。 前半では、そもそもの話として「なぜコスト最適化が重要なのか」「何が難しいのか」「何をすべきなのか」といったことを述べます。これは、当たり前すぎて逆に陽に語られることが少ない (とわたしは感じています) トピックで、一度しっかり言語化しておいてもいいかなと考えたからです。内容のほとんどはわたしの脳内ダンプで、クックパッドという会社のコンテキストや組織としてのステージが前提になっているため、大多数の組織について当てはまる内容とは限りません。 後半では、コスト最適化の一例として、リザーブドインスタンス (以下 RI と略記) を維持管理するためのフローと、それを支えるモニタリング

はじめに システム本部 IT 統括部 IT 基盤部 副部長の土屋です。 現在は DeNA のインフラ基盤全体の管理を行うと同時に，ゲーム・エンタメ・動画配信・ヘルスケア・スポーツなど様々なサービスのインフラ運用を担うグループのマネージャを兼任しています。 この度，「 WEB+DB PRESS Vol.117 」の特集 2「AWS/GCP コスト削減」を執筆させて頂きました。発売日は 2020 年 6 月 24 日 (水) です。このブログでは本特集の概要と見どころをご紹介します。 特集の概要 本特集では，AWS と GCP のコストコントロールについて解説します。目次は以下の通りです。 第 1 章 コストコントロールの重要性 第 2 章 オートスケーリングの導入 第 3 章 在庫インスタンスの活用 第 4 章 インスタンスの集約 第 5 章 オブジェクトストレージの最適化 第 6 章 確約

コスト最適化のご相談をいただくなかで、NAT Gateway に不要なコストが掛かっているパターンが多くみられます。また、そのような環境に限って NAT Gateway にかなりのコストが掛かっていることを把握されていないケースも少なくありません。 今回は見落としがちな NAT Gateway で無駄なコストが発生してしまうケース、何処へのアクセスで NAT Gateway を浪費してるかを確認する方法、そしてどのような改善パターンがあるかをご紹介します。 （本記事中で記載の価格はいずれも、執筆時点の東京リージョン価格を参考にしています） 目次 よくある構成 NAT Gateway に関わる料金のおさらい NAT Gateway 料金 AWS データ転送料金 実際の料金例 何が NAT Gateway を使ってるのか見当がつかない データ通信の方向を確認 VPC フローログから NAT G

2020/04/14 Fin-JAWS 第11回 最近の金融AWS事情 ~2020春~ の登壇資料です。

昨年のre:Invent 2019で発表されたAmazon Builder's Libraryを一通り読んでみました。通勤電車で読んでいたのですが、途中で冬休みに突入してしまい少し時間がかかってしまいました。途中で日本語にも対応していることに気付いたのですが、折角なので全て英語で読んでみました。 aws.amazon.com Amazonにおける大規模分散システムの開発で得られたノウハウが公開されているのですが、昨今マイクロサービスの普及もあり、Amazonのような規模でなくとも分散システムに関するノウハウが重要になりつつあります。もちろんAWSのインフラや規模感に依存する部分も多々見られるものの、大規模な分散システムを運用した上で得られる知見というのは得難いものですし、一般論として参考になる部分も多く、とても有用なコンテンツだと思います。 全体を通して共通して述べられていたのは以下のよう

こんにちは。ABEJAのインフラ管理してる村主 @rwle1221 です。 本ブログは ABEJA Advent Calendar 2019 の11日目です。 今日は、みなさん記憶に新しい2019年8月末に発生した AWS の東京リージョンの AZ 障害について、どのようにしていればサービス影響を与えずにシステムを稼働させられたのか。という話をしたいと思います。 振り返り 障害の詳細報告はこちら aws.amazon.com 有志によるまとめはこちらから piyolog.hatenadiary.jp 基本は「AZレベルで冗長化していれば問題ない」 中の人に聞くと「AZレベルで冗長化していれば問題ない」とのことでした。 しかし、2番目の方の記事を見ると有名どころのサービスが割と止まっていました。 じゃあ上で紹介されていたような会社がAZレベルの冗長化が出来ていなかったのか。 ※ ALB/WA

はじめに 昨年の12月から約10ヶ月ほど、とあるベンチャー企業のAWS環境を改善していました。今はその会社にいないのですが、会社の Jira と Confluence 以外にも知見をまとめておいたほうが良いかなと思ってアドベントカレンダーに書くことにしました。 組織の状況 以前にエンジニアが大量に退職したことにより、大量のメンテナンスできないソースコードがありました。それとともに、何の用途で動いているか分からないEC2サーバーもたくさんありました。 Technology & Infrastructure チーム（以下TIチーム）というのがあったのですが、障害対応をする人たちと数年がかりで新しい基盤を作っている人たち（たぶん目前の問題を諦めた人々）がいて、いわゆるサバイバルモードにありました。ちなみにアプリケーションのバグの量も半端なく、バグ修正チームが数年単位で存在しています。 このTIチ