初めまして、サーバーサイドエンジニアのホルモンと申します。あだ名です。レバーは苦手です。 運用に2年間携わったあと、新規開発を進めている間に意識していたことについて紹介したいと思います。 テーマ 新規開発・運用問わず、開発をしたいのに開発を進められないときがあります。そうです。 「開発サーバーやJenkins上で起きたエラー（異常系）に対する調査及び対応作業」です。 エラー対応が発生する流れのイメージ 新規成果物を反映する エラーが出る_(:3」∠)_ 調査をする 対策をする エラーが出てしまうと当初予定していない調査や対策をすることになるため、開発コストとなってしまいます。開発中のエラーゼロはとてもとても難しいですが、多いのはプロダクトとしても健全ではありません。 エラー対応コストを減らす方針として2つの観点があると考えています。 観点1: エラーを起こさせない 観点2: 平常時を知る
こんにちは。クラウド運用チームで SRE をしている飯塚です。 今回は、MySQL のレプリケーション機能を約10年もの間ずっと使ってこなかった私たちが、レプリケーションを使った高可用性構成に移行するための取り組みの中で学んだことについて紹介します。 背景 巨大なテーブルへの primary key の付与 トランザクションサイズが大きい場合には tmpdir に注意 mysqldump で絵文字が消えていないか要チェック mysqldump が Error 1412: Table definition has changed... で失敗する mysqldump したデータのリストアが Duplicate entry 'xxx-yyy-PRIMARY-n_diff_pfx01' for key 'PRIMARY' で失敗することがある mysqldump したデータのリストア時のディスク
こんにちは、技術部SRグループの菅原です。 最近、Ninja650からNinja1000に乗り換えました。パワーがあるせいで３速発進・４速発進が平気でできてしまい、シフトワークがどんどん下手になっています。精進したいものです。 この記事では、Amazon RDS/Auroraをクローンするシステムを作った話を書きます。 Amazon RDS/Auroraをクローンするシステム サービス開発を行っていると、調査や検証でプロダクション環境で使われているデータベースが必要になることがあります。開発環境やステージング環境にもデータベースは存在するのですが、プロダクション環境のデータでしか再現しないバグの調査や、プロダクション環境のデータ量でのスキーマ変更の負荷の検証など、開発環境やステージング環境のデータベースではできない作業も多いです。しかし、オペレーションミスや個人情報へのアクセスを考えると、
MySQLで3億レコード物理削除した話 はじめに こんにちは。webエンジニア社会人をしている ningenMe です。 タイトル通り。MySQLで3億レコード物理削除した話。 ちょっとハマったので備忘録。 はじまりはアラート はじまりはアラートだった。 僕が運用・保守しているバッチサーバでは、mysqlからちょうど直近1ヶ月分のデータを毎日1回selectする定期処理をしている。 いつもなら1時間程度で終わる処理のはずが、その日は7,8時間経っても終わらずアラートが鳴り止まない.....。 原因追求 とりあえずリトライしたり、ログ見たりしたもののあんまり悪いところがなかった。 クエリもちゃんとindex効いてる。なんでだろうと思ったらDBの容量が結構大きくなっていたことに気づいた。 3億5千レコード。インデックスちゃんと効いてたので多分普通に遅いだけっぽい。 必要なデータ取得は1ヶ月分で
私たちの日常業務で使われる管理画面は、大量の情報と複雑な機能で構成され、利用難度が高い傾向にあります。検索性の乏しい管理画面の一覧から1つの情報を見つけるために、どれだけの時間を費やしているでしょうか。 1億円の工数をかけて開発した機能も、低品質なデザインでは、機能の存在に気付かれなかったり、間違って使われたりと、期待した業務コストの削減に繋がりません。これでは、1億円を捨てたようなものです。 使い勝手の良くないデザインは、ユーザーだけではなく、開発者にも悪影響を及ぼします。複雑な構造と分かりにくい操作体系の管理画面は、開発やテストの手間を増やし、その後の機能拡張も難しく、改修コストも増大します。 これらのリスクを抑えるためには、UIデザインの基本原則を理解し、適切に管理画面を設計することが重要です。 私たちは管理画面のUIデザインの改善やリニューアルを手掛けることも多いのですが、その経験
こんにちは、大前です。 久々に AWS MediaServices 以外の記事を書く気がします。 今回は、掲題のアップデートの紹介です。 Amazon EC2 Auto Scaling now supports Instance Refresh within Auto Scaling Groups どんなアップデートか Amazon EC2 Auto Scaling（以下 Auto Scaling）にて Auto Scaling Group 内のインスタンスを最新化する事が出来るようになりました。 今まで、 Auto Scaling Group の起動設定を変更（例えば、AMIの更新など）した後に既存のインスタンスを最新化するには一手間が必要だったりしたのですが、今回追加されたこの機能を使用するだけで、最新の起動設定で起動されたインスタンスに置き換える事が可能となりました。 今まで痒かった
Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのホスト名を変更しましたが、インスタンスを再起動、または停止してから起動すると、ホスト名が元のホスト名に戻ってしまいます。 簡単な説明 EC2インスタンスを再起動したり、停止してから起動したりしてもホスト名を維持するには、そのインスタンスに該当する設定ファイルにホスト名を追加します。 **注:**次の手順は RHEL 7、8、9と CentOS 7、8、9に適用されます。他のディストリビューションについては、後述のリソースを参照してください。 システムホスト名の変更 RHEL 5、 6、CentOS 5、 6、または Amazon Linux を実行している Amazon EC2 インスタンスに静的ホスト名を割り当てるにはどうすればよいですか? SLES を実行している Amazon EC2イン
概要 インフラエンジニアとしてAWS基盤の構築・運用に携わって早1年が経ちました。 今回は自分がCloudFormationを運用する中で培ってきたノウハウや勘所をご紹介したいと思います。 なお、これがCloudFormationのベストプラクティスだとかそんなことを言うつもりはなく、 あくまで自分がこう考えてきたぞというものなので、ご参考程度にお願いします。 いろんな考え方があると思いますので、ぜひマサカリコメントお待ちしてます。 どの程度の規模で運用してきたか? サービスとしてはビッグデータ分析プラットフォームのようなものを構築しておりますが、 AWSの規模感としては大体こんな感じです。 AWSアカウント：2つ 1つは開発環境・内部結合環境用 1つはステージング環境、本番環境用 環境数：5面 開発環境 内部結合環境 ステージング環境1 ステージング環境2 本番環境 利用しているAWSサ
初めましての方は初めまして。お久しぶりの方はお久しぶりです。虎の穴のY.Mです。 このブログが始まった頃に、よく記事を書いていました。 月日は流れて、現在はEC開発のリーダーをやっております。 今回は技術的な内容というよりは、開発プロセスの内容を少し書きます。 書こうと思ったワケ 弊社のブログを眺めていたところ、これまで虎の穴の開発文化を紹介したことがなかったなと感じました。 チームでの開発をする上では、技術力はもちろん大事ですが、そのチームの開発文化が品質に大きく影響してきます。 ブログを読んでいただいている皆さんに、少しでも「こんな仕事のやり方をしてるよ」というのを知ってもらうべく、久しぶりに筆をとりました。 今回はそのとっかかりとして、一番エンジニアが頭と心を痛めるであろう『障害の事後対応』について書きます。 せっかくオタクエンジニアとして書くので、ちょっとゲーム仕立てにしてみます。
latestタグや書き換えるためのタグ（develop, stagingなど）を使って、本番で運用するのはやめましょう。 コンテナイメージのキャッシュ状況やリリースフローによっては予期しない形で 予期しないバージョンが本番で起動する可能性があります。 本記事では、どのプラットフォームやツールで発生したかについては記載しません。 本題はそこではないのと、そもそも運用が間違っているので 記述しても余計な枝葉になるからです。 この記事ではどういうことが起きたか、について書きます。 どういうことが起きたか サービスで、dockerイメージのlatestタグを使って本番運用していた。 全コンテナをgraceful restartしたようだ。（つもりだったが・・・） 別の作業中、管理画面の表示がおかしくなっているという話が出てきた。 そこで調べてもらったところ、なぜかリリースしたはずの機能が正常に機能
（この記事は 地平線に行く とのマルチポストです） 本番環境でやらかしちゃった人 Advent Calendarで、このパターンのやらかしはなかったのでキーボードを叩くことにしました。 番外編のつもりでお楽しみください。 この記事が、新たな障害発生を防ぐことにつながれば幸いです。 何をやったのか ある日、ちょっとした調査のために本番データベースのデータを確認することになりました。 （個人情報が格納されているようなシステムではなかったので、必要であれば本番データベースへのアクセスが許されていました） もしメンテナンスがあればそのタイミングでやればよかったのですが、直近では特に予定はないとのことでした。そのため、システムが動いている状態のまま作業をすることにしました。 ごく単純な SELECT を実行するだけのつもりだったので、システムに影響がないと判断したためです。 その際、万が一コピペをミ
Amazon RDS 認証局証明書 rds-ca-2019 は、2024 年 8 月に期限切れになりました。RDS DB インスタンスまたはマルチ AZ DB クラスターへの接続に証明書検証付きの Secure Sockets Layer (SSL) または Transport Layer Security (TLS) を使用しているか、使用する予定がある場合は、新しい CA 証明書 rds-ca-rsa2048-g1 の使用を検討してください。現在、証明書検証付きで SSL/TLS を使用していない場合でも、CA 証明書の有効期限が切れている可能性があり、証明書検証付きで SSL/TLS を使用して RDS データベースに接続する予定がある場合は、新しい CA 証明書に更新する必要があります。 Amazon RDS では、AWS セキュリティのベストプラクティスとして、新しい CA 証明
技術部 SRE グループの id:itkq です。2019 夏アニメで一番好きな作品は Re:ステージ！ドリームデイズ♪ です。この記事では SRE が運用している退職処理の自動化について説明します。 退職処理とは 入社後に業務のための様々なアカウントを作成するのと反対に、退職時にはそれらのアカウントを無効化する必要があります。これを退職処理と呼んでいます。SRE が管轄している典型的な例では、SSO に対応していない SaaS のログインアカウント・AWS の IAM User・データベースの個人ログインユーザなどが該当します。これらのアカウントは社員によって要否が異なったり必要な権限が異なるため、入社時に一括で用意せず必要に応じて申請してもらう形をとっています。一方で退職時にはそれらのアカウントをすべて無効化する必要があります。 退職処理は繰り返され、自動化の余地のあるタスクです。また
運用現場が「つらい」のはなぜかについて説明した簡単な資料です。 運用自動化や運用改善をする前に、一度じっくりと考えるための土台として作成しました。 (2019-09-12更新) - 「ダイジェスト」を追加しました。 - 「参考: 処方箋としての資料」セクションを追加しました。 (2…
アラート起因で調べるベースの運用とログの話を書いておく。 状況確認 状況確認は大事。ひとまず初動で原因が分かると嬉しいので ざっくり状況確認。 ログを読む エラーログを読む なにも出てなかったらWARNを読む メトリクスを見る 5xxエラーを見る どのサービスがダメになってる？ 状況別調査 状況別に自分が見ているところをざっくりメモベースで書いておいた。 変なレスポンスが返っている ログを見る リクエストに紐付いた一意なIDを元にログで処理を追いかける 外部通信した時はこの一意なIDと一緒にログに出力しておきたい レスポンスが遅い レスポンスタイムを見る 特定のリクエストだけ遅い場合があるので、基本的にAverageじゃなくてPercentileを使う 依存先のサービスも見る サービスのCPU使用率見る 特定のインスタンスのCPU使用率を見る RDBやバックエンドのCPU使用率を見る IO
[SRE]原文 Do-nothing scripting: the key to gradual automation – Dan Slimmon (English) 原文著者 Dan Slimmon 原文公開日 2019-07-15 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1724日前 Twitterで報告済み 編集 どんな運用チームにも、まだ自動化するところまで手が回っていない手作業があるものです。 トイル (toil) が完全に無くなることは決してありません。 成長企業のチームに非常にありがちなのが、インフラの変更手続きやユーザーアカウントのプロビジョニングが、最大のトイル源となっているケースです。 後者の例について手順の一部を書き出してみると、たとえば以下のようになるでしょう: ユーザーのSSHキーペアを作成する 公開鍵をGitに
はじめに エンジニアのウエです。Timers inc.では、ビジネス部門の一人として 配送・印刷・決済に関わる施策立案・業務改善を推進しています。また開発チームのプロダクトマネージャとして、顧客対応チームのマネージャとして、様々な役割でサービスに関わっています。 BizDevOps を通じた 効率化や改善に関わり、とても充実した日々を送っています。 今回の記事では、AWS Chatbot (チャットボット) を Slackへのコストアラート通知に利用した例を記載します。 前提 CloudWatch の Billing を利用するため、あくまでも概算です。 事前準備 ブラウザで Slack に bot用アカウントでログインします。 通知に利用する SNS トピック作成( us-east-1 )します。 手順 AWS chatbot から Client を作成します。 通知先として Slack
以前に取得されたスナップショットからRDSを復元して、現在のRDSと付け替える方法。 ポイントは以下。 DBインスンタンス識別子の値は、EC2と接続するためのエンドポイントのprefixを兼ねている 同じ識別子で復元できない 別の識別子で復元 -> 既存の識別子を変更 -> 復元分の識別子を元々の識別子に変更 これでエンドポイントの値は変更されないので、Webサーバー側との接続に影響を与えない 復元したインスタンスのセキュリティグループを既存と同様にセットし直す スナップショットからインスタンスを復元 RDSダッシュボード - スナップショット - 復元したいスナップショットを選択 スナップショットのアクション - スナップショットの復元 DBインスタンスの復元画面が表示されるので、情報を入力 デフォルトになっている部分を抜粋 マルチAZ配置 : 選択 DBインスタンス識別子 : 復元して
NetflixのシニアパフォーマンスアーキテクトであるBrendan Gregg氏による、Linuxサーバにログインして60秒でまず調べることのまとめ。 パフォーマンス問題でLinuxサーバーにログインしたとして、最初の1分で何を調べますか？ Netflixには、多数のEC2 Linuxからなるクラウドがあり、そのパフォーマンスを監視したり調査したりするための数々のパフォーマンス分析ツールがあります。その中には、クラウド全体にわたる監視を行うAtlasや、オンデマンドにインスタンスの分析を行うVectorがあります。これらのツールは多くの問題を解決する手助けをしてくれますが、各インスタンスにログインし、標準的なLinuxパフォーマンスツールを実行する必要がある場合もあります。 この記事では、すぐ使えるはずの標準的Linuxツールを使いコマンドラインにおいて、最適化されたパフォーマンス調査を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く