タグ

運用とamazonに関するmytechnoteのブックマーク (6)

  • Amazon Connectで月4ドルで電話発信する仕組みを構築する | DevelopersIO

    今までAmazon Connectは受信専用のコールセンターのイメージだったのですが、発信専用として使うと、非常に安価に電話発信機能をAWSに組み込むことができます。 「システム障害アラート、やっぱり電話で発信したいよね…」 システム運用の要である障害アラート。異常発生に即対応するためのアラート運用は重要です。アラートの通知先としては代表的なものにメールがありますし、最近ではSlackなどのチャットツールを併用している現場も多いと思います。 しかし、やっぱり昔から一番緊急度が高いアラートとして利用されているのは、「電話」じゃないでしょうか。そう、聞きたくないんだけれど聞かないといけないアレです。 ただ、電話によるアラートをシステムに組み込むのって敷居が高そうじゃありませんか?サードパーティーのサービスを契約したり初期費用がかかったり時間も手間もかかったり… そこでAmazon Connec

    Amazon Connectで月4ドルで電話発信する仕組みを構築する | DevelopersIO
  • 【レポート】ロマサガRSの大規模トラフィックを捌くAmazon ECS & Docker 運用の知見 #AWSSummit | DevelopersIO

    こんにちは。サービスグループの武田です。 プレイしてますか?ロマサガRS。私はやってます。総戦闘力はもうすぐ95万くらいです。メインスタ半にSSスタイル2倍キャンペーンなど、ハーフアニバーサリーのイベントで毎日忙しいですよね。AWS Summitに参加している場合じゃないですよ!いや参加している場合ですけども。 2019年6月12日(水)から14日(金)の3日間、千葉県幕張メッセにてAWS Summit Tokyo 2019が開催されています。こちらで講演されたセッション「I3-04 ロマサガRSの大規模トラフィックを捌くAmazon ECS & Docker 運用の知見」を聴講しましたのでレポートします。 AWS Summitでは全セッションで撮影が基NGということですので、文字だけでお届けします。 概要 ロマンシング サガ リ・ユニバースではローンチ直後、想定の数倍以上のトラフィック

    【レポート】ロマサガRSの大規模トラフィックを捌くAmazon ECS & Docker 運用の知見 #AWSSummit | DevelopersIO
  • ECSのバックエンドをEC2からFargateに変更するにあたり知っておくとよさそうな事 - コネヒト開発者ブログ

    こんにちは。インフラエンジニアの永井(shnagai)です。 これまでEC2バックエンドでECSを運用してきたが、Fargateを採用するにあたり、EC2バックエンド時と比べた差分についてまとめてみました。 内容は、ざっくり下記5項目について。 NW(awsvpc) タスク定義 サービス AutoScalling メトリクス/ログ Fargateをやってみたというのは出たての頃にやったので、今回は番運用を考えるにあたり知っておいたほうがよさそうな点についてまとめてます。 tech.connehito.com NW(awsvpc) アーキテクチャ的に一番大きく変わるのは、NWの部分だと思う。 EC2上で、タスクを動かすときはデフォルトだと「bridge」が指定されるので、ホスト経由で外部と通信を行っていた。同一タスク(コンテナのリッスンポートが同じもの)を効率的にEC2上で動かすために、動

    ECSのバックエンドをEC2からFargateに変更するにあたり知っておくとよさそうな事 - コネヒト開発者ブログ
  • AWS運用でよく聞く不安とその対策を書き出してみた | DevelopersIO

    はじめに 皆さまがシステムを運用にするあたり、様々な不安を抱えていらっしゃると思います。 そういったよくある「不安」を書き出し、解消するための対策や参考ページなども記載しましたので、記事をご覧いただいている皆さまには抱えている不安を淡々と潰していただければと思います。 【ケース1】大量のアクセスによる高負荷への不安 近日中に Web サイトの広告を出す予定だが、現状のままで増加するアクセスに対応できるのか不安がある 以下のような対策が考えられます ELB(Elastic Load Balancing)を使用し、Webサーバー(Amazon EC2)の複数台構成にする アクセス数や負荷に応じて自動で Webサーバー(Amazon EC2)の台数を増やす(スケールアウト)、減らす(スケールイン)ために AWS Auto Scaling を使用する ELB の暖機申請(予め AWS へ連絡して

    AWS運用でよく聞く不安とその対策を書き出してみた | DevelopersIO
  • オンプレミスから AWS に移行して変えた 3 つのこと

    7 月に開催された「JAWS-UG 三都物語 2014」でも発表したとおり、自分が関わっているプロダクトをオンプレミスから AWS に移行しました。 JAWS-UG 三都物語 2014 に登壇しました 移行して 2 ヶ月ほど経ちましたが、目立った障害もなく安定した運用を続けています。スライドでも少し触れていますが、これまでのやり方を大きく変えるキッカケにもなりました。 今回は「オンプレミスから AWS に移行して変えた 3 つのこと」と題して、社外に公開できる範囲でご紹介します。 稼働中のサーバに変更は加えない いわゆる Immutable Infrastructure の考え方を取り入れました。最初は流行りに乗りたかったという気持ちが大きかったのですが、今では昔のやり方にはもう戻れません。 オンプレミスでは番稼働中のサーバにログインして何か変更するということが当たり前に行われていました

    オンプレミスから AWS に移行して変えた 3 つのこと
  • Amazon EC2(Linux)システム管理で知らないとハマる5つの環境設定 | DevelopersIO

    ども、大瀧です。みなさん、EC2をバリバリ使ってますか?使いたいときにすぐ使える仮想マシンとして、開発・検証から番まで幅広く活用されていると思います。 日頃EC2を業務で運用する中で、EC2インスタンスをコピーすると意図しない環境設定に変わってしまうというトラブルが度々あり、cloud-initというツールに拠ることがわかってきました。 「EC2インスタンスのコピーなんて、一旦インスタンスを作成したあとはあまりやらないのでは?」と思われがちですが、EC2独特の制限などもあり、実際の運用では思ったよりも頻繁にインスタンスのコピーが必要になります。インスタンスのバックアップ&リストアなどはイメージしやすいと思いますが、それ以外にも意外なケースとして以下があります *1。インスタンスのコピーは、AMI(Amazon Machine Image:インスタンスのバックアップ)を取得し、新規インスタ

    Amazon EC2(Linux)システム管理で知らないとハマる5つの環境設定 | DevelopersIO
  • 1