バウンスしすぎて Amazon SES から追放された俺たちは Mailgun と SendGrid に国を作ることにした - ANDPAD Tech Blog
これは何 どのように技術選定してますか。よく聞かれます。SREチーム 鈴木心之介 です。しかし説明が難しい。難しいですが説明の助けになってほしく思い、技術選定を文書化した DesignDoc から1枚を公開してみました。 DesignDoc とは、ある程度の大きさや複雑さがあり一言で説明の難しい技術選定について、文書化したものです。これを通じて、技術選定をどのように行うか組織内に広めようとする試みです。2021年1月頃から始めています。 題材は、メール配信の冗長化をRailsで実現した tech.andpad.co.jp を、インフラ視点から技術選定した DesignDoc です。このメール配信SaaSの選定は2019年末頃に実施したもので、DesignDoc の取り組みを始めていなかった頃でした。時が経ち、ソースコードやSaaSの構成からは意図を読むことが難しく「なんじゃこれ」って質問を
定期実行するLambdaが「起動しなかったこと」を検知するCloudWatch Alarmを作る | DevelopersIO
Lambdaを定期実行する仕組みをよく作ります。 1時間に1回起動する 1日に1回起動する これらのLambdaが「起動しなかった場合」に通知が欲しくなったので、CloudWatch Alarmを作ってみました。 実際にLambdaが起動しない事象に遭遇したことは無いですが、このAlarmがあると、「ちゃんと起動しているよね？」というモヤモヤが解消されます。万が一に気づける保険ですね。 おすすめの方 定期実行するLambdaが「起動しなかった場合」のCloudWatch Alarmを作りたい方 定期実行するLambdaとCloudWatch Alarmを作成する sam init sam init \ --runtime python3.8 \ --name Lambda-No-Start-Alarm-Sample \ --app-template hello-world \ --pack
私がサーバレスに全面移行した理由はセキュリティです。セキュリティパッチも当てず放置してしまっていました。
私がサーバレスに全面移行した理由はセキュリティです。セキュリティパッチも当てず放置してしまっていました。 本記事は「サーバを一度構築したら、正常にレスポンスがあるうちは放置する」ような運用をしている方に向けた記事です。 私は学生時代に、「パーツあげるからサーバつくって運用してみなよ！！」と仲のよかった教授がいってくれたことでサーバ構築をはじめました。CentOS入れて、Apache入れて、よくわからないけどiptablesをoffにしたらすごい公開できた！！という体験はとてもよかったです。 その後、アプリをつくるようになって、レンタルサーバではスペックが足りなくなったので、お名前ドットコムでVPSを借りて、AWSが登場したら「すごい！構築したインスタンスをそのままスケールアップできる！！」と勢いのままEC2に移りました。Ansibleで構築自動化のレシピをつくって構築して、運用という名の
クラスタのノード欠損を復旧しようとしてクラスタを丸ごと落とした話 - Qiita
これは、私が若…くはないけどピカピカのAWS1年生だった、数年前のお話です。 何をやらかしたのか やらかし前の状態 本番運用しているWebアプリケーションの裏側に、EC2インスタンス3台でクラスタを組んだ某データストア製品を使用していました。データはクラスタ内でレプリケーションされており、1台がダウンしただけならクラスタは稼働を継続できます。2台がダウンするとクラスタ全体が機能しなくなります。 ある日、3台のうち1台で障害が発生してインスタンスへ疎通できない状態になりました。この時点ではクラスタは正常に応答しており、あと1台ダウンしない限りはサービスに影響が出ない状態でした。 まず、ダウンしてしまったインスタンスを再起動して復旧させようとしました。ところがEC2マネジメントコンソールから再起動、停止を選択しても障害中のインスタンスは反応しません。そして私は間違いを犯します。 やらかしたこと
AWS Amplifyで高負荷に耐えられるWebサイトを早急に立てて、Webフロントコーダーが運用を回した話。 - Qiita
AWS Amplifyで高負荷に耐えられるWebサイトを早急に立てて、Webフロントコーダーが運用を回した話。AWSWebamplify はじめに こんにちは、AWS Amplify Advent Calendar 2019の12日目担当、Oceans株式会社 竹本と申します。 クリスマスまであと2週間、アドベンドカレンダーと共にクリスマスを一緒に過ごせる素敵な方と出逢わなければならない私のカウントダウンも進行しており大変焦っております。 さて、今回は「高負荷に耐えられるWebサイトを早急に立てて、Webフロントコーダーが運用回せるようにしたい！」と言う焦っている方向けに、弊社の事例をお伝えします。 それぞれの詳細な手順は他の方がたくさん上げて下さっていますので割愛しつつ、組み合わせて商用環境で使ってますよと言う事例を参考にして頂ければと思います。 （静的Webサイトのホスティングのお話で
#技術書典 に出展する『AWSの薄い本 IAMのマニアックな話』はこんな本 - プログラマでありたい
たびたびTweetしておりますが、2019年9月22日の技術書典7に、『AWSの薄い本 IAMのマニアックな話』という本を出展します。名前の通りAWS本ですが、IAMだけを取り扱っています。初の同人誌を引っさげて、技術書典デビューします。 IAM本の目的 書いた本はIAMの特化本ですが、何故IAMと聞かれるのでここに書いておきます。AWSが不正利用されて100万円の請求が来たというようなニュースが、たまにネットを駆け巡ることがあります。原因の多くがIAMのアクセスキーをGitHubに誤ってコミットしてしまい、そのキーを不正利用されたケースです。そういった事態を防ぐために正しくIAMを知って貰いたいのです。 IAMは、AWSの利用権限を管理する極めて重要な機能です。AWSには多種多様な機能があり、IAMはそれに応じて様々な記述方法で権限を設定できるようになっています。その分設定項目が多く、I
AWSでAZ障害が起きたのでなるべく影響を受けない構成の考えを書いておく - なんかかきたい
AZ障害は受け入れるしかないクラウド時代のインフラ ただの日記。 今日の昼、AWSを利用している人たちは大変だったところもあると思う。 AZの一つが丸々機能しなくなる大きなAWSの障害があり、AWSを利用して運用されていたサービスは多かれ少なかれ影響を受けることになった。 完全に雰囲気で書いてしまうが、今回のAZ障害で影響を受けたサービスは思ったより多かったように感じる。 というのもAWSではアベイラビリティーゾーンの障害は発生するものと考え、本番運用するのであれば、マルチAZ構成を取るのがベストプラクティスとされているので、 マルチAZ構成を取っていれば影響なんてないんじゃないの普通、と思ってしまうと思う。 インフラ屋さんでもそう思ってしまうし、インフラ屋さん以外ならなおさらなんで重くなるのかわからないと思う。 幸い自分の運用しているサービスでは影響が軽微だったので、完全に想像にはなって
AWSネットワーク構成図の手動更新が辛い？よろしい、ならばCloudMapperだ
株式会社ビズリーチで、SREエンジニアとして勤務しているmassです。2017年4月に入社してから、HRMOSというサービスのAWSのインフラを管理したり、アーキテクチャの設計・構築をしたりしています。 今回は、入社してから半年経ったらいつのまにかサービスのネットワーク管理者になっていて、そこで発生した問題と、それを解決するのに非常に役立ったCloudMapperというOSSを紹介したいと思います。 発生した問題 私がネットワーク管理者を引き継いだ段階では、ネットワーク構成図が作成されておらず、以下の問題が発生していました。 ロードバランサーを止められない 用途不明のロードバランサーが存在したため、停止を検討した。 しかし、どのリソースから利用されているか見えず、不用意に停止できなかった。 用途不明なEC2インスタンスの調査ができない AWSからメンテナンス通知が来た対象が用途不明なEC2
AWS特有の運用イベントまとめ（非障害系） | DevelopersIO
【ACM】 サーバー証明書の有効期限切れ／自動更新失敗 ACMは、CloudFrontとELBと連携してサーバー証明書を提供するサービスです。 ACMで発行する証明書は1年毎に更新する必要がありますが、基本的には自動更新されます。 ただし、場合によっては自動更新が失敗するケースがあります。 検証の仕組みは、以下のドキュメントを確認してください。 自動ドメイン検証の仕組み 自動検証に失敗した場合、EメールおよびPersonal Health Dashboardで通知されます。 自動検証に失敗した場合 また、外部で発行された証明書を利用している場合は、手動で更新する必要があります。 再インポートの手順は、以下のドキュメントを参照してください。 証明書の再インポート EV証明書が必要なケースでも無ければ、ACMで証明書を取得してオペレーションが発生しないようにしておきたいですね。 【Route
個人で運用している Web サービスをどう管理しているか 2018年版 - r7kamura - Medium
個人で運用している幾つかの Web サービスについて、自分がどう管理しているかを振り返る。 実験には Heroku を利用習作につくったアプリやβ版段階のアプリは、Heroku で動かしている。Heroku を使う場合のより具体的な条件としては、データベースが明らかに無料枠に収まりそうで、24時間動いていなくてもまあ誰にも怒られそうないような場合。Slack 用の Bot や、nippo という日報専用サービスのクローズドβ版などを主に置いている。 メリットに感じている部分は、無料で使えること。デメリットに感じている部分は、サーバが US に配置されることと、データベース系の Add-On が高くつくこと。例えば日本語圏向けのサービスだと、通信時間がそこそこ長くなり、結果的にサービスの体験が悪くなる（昨今の平均的な Web サイトの速度はまだまだ遅いので、それと比較すると悪くなるというほど
【登壇資料】目的別、サーバーレスアーキテクチャの教科書！これのときはこう！【アーキテクチャ20連発】 #cm_osaka | DevelopersIO
大阪でサーバーレスの話をしてきました クラスメソッドの開発を知る！大阪勉強会 第7回 これから始めるサーバーレス！〜最新サービス使いこなし術〜で スピーカーとして登壇しました。参加率が非常に高く、多くの方にご参加いただきました。誠にありがとうございました！ 本記事では、勉強会でお話しした「目的別、サーバーレスアーキテクチャの教科書！これのときはこう！」の発表資料を公開します。 発表資料 内容 本セッションでは、これからサーバーレスを始める人向けに、サーバーレスとは何か？という話から、具体的にどのようなアーキテクチャを構築するのか？というお話しをさせていただきました。 サーバーレスアーキテクチャパターン 本セッションでは、サーバーレスアーキテクチャのパターンを20種類ご紹介しました。サーバーレスと言えるアーキテクチャは20種類では語りきれないほど沢山ありますが、今回は独断と偏見で選んでみまし
AWS でいままで起きた大規模障害を振り返る - Qiita
目的 2017/3/1 に us-east-1 の S3 大規模障害がありました。過去にもいくつか発生しているのと、いつ使っているリージョンで同じ事態が起きてもおかしくないと思い、これを機に過去どのような障害があったのか遡って調べました。 所感 毎年どこかのリージョンで大規模な障害が起きている ap-northeast-1 で起きていないのはたまたま、運がいいだけ AWS は復旧時間の改善・可用性向上に全力を尽くしているものの、未知の障害はいつかどこかで起きるもの ステータスダッシュボードは時に嘘をつく クラウドシェアトップである AWS はインターネット全体の SPOF になりつつある Chaos Monkey の思想は必須 報告書読むの面白い AWS の中身がすこし透けて見えてきます 前回データセンターについて調べたことが役に立った AWS のデータセンターに侵入する（妄想で） - Q
サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開
サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 米国でビデオオンデマンドサービスを提供しているNetflixは、Amazonクラウド上でわざとシステム障害を起こすためのツール、Chaos Monkeyをオープンソースで公開しました。 Chaos MonkeyはAmazonクラウド上で使うツール。Amazonクラウド上のインスタンスをランダムに落としまくることで、サービスに対して仮想的な障害を引き起こしてくれます。 NetflixはこのChaos Monkeyを実環境で使うことで、本物の障害が起きたとしてもサービスが継続できることをテストし続けてきました。Netflixのブログ「Chaos Monkey released into the wild」から引用します。 There are many fail
DBのint枯渇を目の前にした僕らは - Qiita
MySQLのint型は符号付きで -2147483647〜2147483647 の範囲をサポートし、レコードを記録する際にこの範囲を超えて記録しようとするともちろんエラーとなります。 これは、長い運用の末にデータが膨大になり、ついにintのサポート範囲が枯渇寸前となった話です。 方針 DBはAWS Auroraを使用しており、アプリケーションはRailsで構築されています。RailsのMigrationはデフォルトでidカラムをAUTO INCREMENTのint型で作成します1。サービスの特徴としては他のサービスと比較すると高トラフィックに晒されるもので、DBに大量のログを記録する必要がありテーブルによっては1ヶ月で1億レコード以上記録されるものもあります。対処方法を検討し始めた時にはidは既に18億を超えており、やるべきことは対象のテーブルのidカラム、及びそのidを関連として保持して
サーバーレスな外形監視ツール pingbot | TORI
サーバレスアーキテクチャーって言葉が流行っているのでその近辺技術に触れてみたくてアプリを一本こしらえてみました. リポジトリは github.com/toricls/pingbot です. 何を作ったか サーバーレスな外形監視ツールです. 1 分ごとに任意の Web サイトに対して http/https リクエストを投げることで外形監視を行い、その結果を保存します. 前回チェック時と比較してステータスが変化した場合、Slack にその旨通知してくれます. 安価かつ安定して任意の Web サイトに対してヘルスチェック(死活監視)を行うことを目的として、AWS Lambda、Amazon CloudWatch Events、Amazon DynamoDB あたりを使っています. サーバーレスアーキテクチャーの構成要素として良く利用されるサービスですね. 管理画面となる Web アプリの方は R
マーケティング担当者にSQLを完全マスターさせた話 - Qiita
普段開発とかしない人達にもデータベースに簡単に触れられるようにしたお話です． 安全なデータベースを作る 本番サービスのデータベースと同等，だけど個人情報的なものは隠しておきたい，よく聞く話ですね． これについては様々なアプローチがあるようですが，できる限り安定させたい＆バッチでやるにしてもサーバの面倒を見たくない，とう方針のもと，RDSのスナップショットを利用して作成することにしました． 処理の流れ RDSが1日1回スナップショットを取っている(これはRDSの機能) RDSのスナップショットが取られると，RDSからイベント通知が投げられるので，SNS→SQSへ届くようにしておく(これもRDSの機能) CloudWatchでSQSのキュー数を監視するようにしておき，キューが1つ以上になると処理用のインスタンスを立ちあげる設定にしておく(CloudWatch，AutoScalingの機能) イ
現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠
RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね（ｷﾘｯ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[EC2]サーバのリソース監視入門 - Qiita![[EC2]サーバのリソース監視入門 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/e4f2dafeca68f2b2c8cc3a6dbe4f2d8b305b43c0/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCRUMyJTVEJUUzJTgyJUI1JUUzJTgzJUJDJUUzJTgzJTkwJUUzJTgxJUFFJUUzJTgzJUFBJUUzJTgyJUJEJUUzJTgzJUJDJUUzJTgyJUI5JUU3JTlCJUEzJUU4JUE2JTk2JUU1JTg1JUE1JUU5JTk2JTgwJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz0wOThlNjk4ZTk3OGYyY2ZiOWI3ODc5ZGYyNzJkOTQyZA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBtb250YW1hJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1kMDM0OWVjYjYxZmMwMzg4ODZkOWI1YmFjZGUxNjhiNQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dff6e9f9eb9e3bb788fd9f8db4ea20187)
[社内勉強会]ELBとALBと数万スパイク負荷テスト![[社内勉強会]ELBとALBと数万スパイク負荷テスト](https://cdn-ak-scissors.b.st-hatena.com/image/square/2d66722d28b188f243f0cd881f7598f699791ab1/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Felbalb-160822022623-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Fate/Grand Orderにおける、ディライトワークス流 AWS 導入&活用術
