こんにちは。小椋です。 「まあ15分ぐらいなら落ちてても実際そこまで困らないけど、基本的には24時間起動していてほしいんだよね……」 という緩めのサービスレベルで稼働しているSPOF気味なサーバー、ありますよね。社内向けのジョブスケジューラーとか、一日に数回なんか集めて分析する奴とか。あんまり表立って言わないだけで、御社にもありますよね？ サービスレベルが緩めだし、ミッションクリティカルでもないので、ただ起動しっぱなしにしてほっとけばいいや……と思いきや、やっぱり止まったら止まったで処置も必要だし、生死確認はちゃんとしないといけないし、そもそも起動しっぱなしなのでお金もかかるし、とか、意外とお金も労力もかかりますよね。 私HDEの社長ですが、サーバ代に関してはかなりケチです！ そういうケースに関しては、場合によってはEC2のAutoScaling Groupで管理すると節約ついでに横着でき
はじめに サーバを運用しているといろいろなことが起こります。 今回はなんらかのトラブルによりインスタンスが正常に起動しない、 ログインできなくなった場合の対応方法をご紹介します。 障害インスタンンスはAmazon LinuxでrootボリュームはEBSということで話を進めていきます。 障害インスタンスを停止する 正常に起動しない、ログインができないインスタンスをstopします。 サーバにログインできないのでマネジメントコンソールやAPIでstopします。 障害インスタンスのルートボリュームをデタッチする ルートボリュームのEBS IDを確認してVolumesへ移動します。 ・DescriptionのRoot Device 「/dev/xvda」をクリック また後でアタッチし直すのでRoot Device名はメモしておきます。 ・EBS ID をクリック ・Volumesに移動します。 ・A
前のブログの続きで、もにかじ7で話した小ネタその2。 実際にサービスでなんかやったというのじゃなく、こういうこと考えてるんだけどみんなどうしてます？って話です。 まずオンプレ時代はサーバのスペックダウンはけっこう大変だったし、頑張ってメモリやCPU引っこ抜いてもそんなに節約にならなかった。 ※CPUやメモリはサーバ価格の一部でしかないし、ラック費用(消費電力)もあるし。 でもクラウド前提だとスペックダウンはとても簡単で、スペック半分にすると価格も半分になる。 そうすると、 『イベントで一時的にc4.4xlarge(8万/月)にして、そのまま最大CPU使用率10%とかで数ヶ月放置されている』 みたいなのはビジネス的な損失という意味で明らかに障害で、監視すべきじゃないだろうか？ みんななんかやってますか？ というようなことを参加者に聞いてみました。 参加者の中では、AutoScalingしてい
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最低限セキュアな構成とは 「最低限セキュアな構成」を次のように定義する。 Webサーバーやデータベースサーバーが直接、インターネットに公開されていない。 公開・非公開に関わらず、特定のポートのみインバウンドを受け付けている。 非公開のサブネットは特定のサブネットからのみインバウンドを受け付けている。 踏み台サーバーは必要な時のみ存在している。 この定義を満たす構成は次のようになる。 構築手順 ざっくりと以下の手順を踏む。 VPCの構築 パブリックSubnetの構築 Subnetの構築 Internet Gatewayの構築 Route
概要 AWSではアプリケーションのデプロイや、システムのスケーリングを自動化することができます。 しかしそれらを実現しようとすると、似たようなサービスの中から用途に合ったものを選ぶ事になると思います。 今回は選択肢となり得るサービスを挙げて、それぞれの出来る事、出来ない事をベースに比較していこうと思います。 比較の軸 以下のように、評価軸を設けました。 サービスの機構として提供されているものは◯とします。 機構として提供されているが、使い難いものは△とします。(例: AWS CLIを利用した場合のみ利用可能など) 機構としては提供されていないが、別の機構などを組み合わせることで容易に実現可能なら△とします。 別の機構などを組み合わせても辛い場合や、実現不可能なら×とします。 デプロイ自動化 まずはアプリケーションのデプロイを自動化するサービスの比較を行います。 以下の4つの選択肢があります
4月から劇団サーバーワークスに加わりました。伊藤です。 社内ではくりゅーと呼ばれております。 AWS環境では、わずか数クリックでサーバーができたり、AutoScalingで自動的にサーバーが増えたり、 オンプレミスの監視運用のスピードでは全く追いつけません。 そこで、今回はAuto Scalingなどで監視対象のインスタンスが自動で増えたり減ったりしても、Zabbixで常に対象インスタンスを自動登録し、監視対象にする方法をご紹介します。 自動構成ツールなどには依存しないので、どんな方法で（マネージメントコンソール、SDK、CLI、API、Elastic Beanstalk等々）構築、運用していても適用できます。 監視対象インスタンスのAgent側設定 zabbix_agentd.confにおいて、以下の点を設定します。 Server=127.0.0.1 #Zabbix-serverのIPも
はじめに Amazon AWS 環境下で Rails 3 のアプリを Nginx/Unicorn で動くように Capistrano 3 でデプロイする手順をまとめました。 以下を前提に話を進めます デプロイ対象のアプリ/DBインスタンスはすでにつくられているとします デプロイ対象のアプリインスタンスのドメインは production.example.com とします アプリインスタンスは ephemeral disk がマウントされているとします プロジェクト名は myproject とします。ご自身のプロジェクト名に読み替えてください アプリインスタンスに SSHログインするための秘密鍵は ~/.ssh/myproject.pem に配置してあるとします RVM を使ってます。rubyenv での設定はこちらの記事が参考になるかと思います デプロイ先ディレクトリの準備 アプリを /va
AWS Amazon EC2 + Amazon RDSを使ってWordPressを構築する | tsuchikazu blog
今頃ですが、初めてAWSを触ってみました。前提知識は全くのゼロからのスタートでしたが、WordPressを構築するところまで出来ましたので、その時の流れをまとめました。 まず、公式サイトやGoogleで調べてもわけがわからないのでドットインストール Amazon Web Servicesの基礎をひと通り見てください。これでAWSの大体のイメージが掴めるかと思います。 WordPressの構築方法 では、早速WordPressの構築に入りますが、調べたところ3つの方法があります。 WordPress用のAMIを使用する CloudFormationのWordPressテンプレートを使用する 手動でEC2+RDSを構築する 一つづつ説明していきます。 WordPress用のAMIを使用する Amazon EC2ではインスタンスを作成するときに、どのような環境を構築するのか、AMI(Amazon
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
