PHPアプリケーションのセッション管理にAWS ElastiCacheを使う | DevelopersIO
こんにちは。望月です。 AWS上でシステムを構築する上で、「AWSのお作法に従う」のは印象以上に重要です。お作法に関しては色々とあるのですが、 *1その中でも一番大きいのは「サーバーは故障するものという前提で設計する」ことにあると思います。例えば、以下の様な点です。 WebサーバやAPサーバなどはロードバランサを介して冗長化し、単一障害点ではなくす 保管する必要のあるデータは全てS3に保管するか、EBSスナップショットを取得する等のバックアップを実施する DBはRDSをできるだけ利用することで、Multi-AZによる障害時自動フェイルオーバーによるサービス継続を実施する 上記１番目の「Web/APサーバの冗長化」ですが、オンプレミスからの移行の際にはこれへの対応が結構大変だったりします。例えば、アプリケーションからローカルのファイルを読み書きするような処理が入っている場合、そのファイルを両
サーバとL2スイッチの接続を冗長化する設計の基本 - GeekFactory
インフラを設計する上で冗長化による信頼性向上は避けて通れない道です。サーバとL2スイッチの接続を冗長化する設計については意外と情報が少ないのでまとめてみました。変なこと書いてたらご指摘ください。 インフラ設計の基本は単一障害点（SPOF）を取り除くことです。構成要素のうち1つが故障してもサービスを維持できるように設計します。構成要素は以下のものが挙げられます： CPU マザーボード メモリ ローカルディスク 電源 FC-HBA NIC LANケーブル L2スイッチ ・・・ ただし、これらすべての故障に備えようとすると費用対効果が割に合わないので、ローカルディスクから下を冗長化する構成が一般的と思います。絶対に止まってはいけないサービスは別ですけどね。 冗長化の種類 サーバを冗長化するにはクラスタを組みます。クラスタはActive-ActiveとActive-Standby（HA）の二種類に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
heartbeatとldirectordを使って自律負荷分散型のWWWサーバを構築する
