03-5946-8400
HOME
AWS運用でありがちなこと
- AutoScaleを設定していても、確実にインスタンスが上がってくる保証がない
- インスタンス上でサービスが正常に稼働しているか、確認できない
- Amazon側の都合でメンテナンスが発生した場合に、サービス側で準備・対応しなければならない
- バックアップ設計（いつ、何を、どこに取るのか）がうまくいかず、リストア時に大変だった
CloudWatch でAutoScaling を有効にすると、CPU使用率などのリソース状況や特定の曜日・時間をトリガーにしてインスタンスを上げ下げでき、コスト効率が上がります。しかし、インスタンスが想定通り立ち上がる保証はなく、起動処理に失敗するケースがあります。
また、インスタンス上で稼働するサービスの監視や、障害発生時の自動復旧の仕組みはカバーしていないため、障害（ユーザーのサービス利用に制限がかかっている状態）に気付くことができず、ユーザーからの指摘で初めて気付いたり、障害対応の初動が遅れることもあり得ます。
AWSサービスのメンテナンスへの配慮も必要です。期限までにインスタンスを再起動しなければならず、サービス停止を回避するためには設計時の考慮が必要となります。
インスタンスのsnapshotを取得する上でも、留意事項があります。例えば、リージョン間転送をする場合、snapshotは一度に一回しか転送できません。東京リージョンからその他のリージョンに1時間おきにsnapshot転送を実施する場合、前回の転送が終わっていないと次の転送を実施できません。また、snapshotはアカウントごとに取得数の上限があり、このことに留意せず設計をすると、取得数の上限に達してsnapshotの取得ができなくなります。
AWS特有の動作や制限を配慮した設計が必要です
AWS上で停止なくシステムを稼働させるために必要なこと
- サービスの継続性を担保するための監視設計と情報収集
- AWSメンテナンス時にもサービスを止めないための設計
- 取得対象データの特性や、目的に応じたバックアップ設計
AWS特性をおさえた設計・運用サービスをご提供します
5000ノード以上の運用実績を持つアールワークスが「技術者による対応」と「自動化の仕組み」を組み合わせてご提案します。
- 「サービスの継続性」という観点と AWS 特性に配慮した監視設計
- 障害の一次切り分けから二次対応までを技術者が対応
- 手順書に落とし込める復旧作業は自動化し、迅速・正確な障害復旧を実現
- AutoScaling が有効でない場合でもインスタンスを自動起動する仕組みの実装
- サーバーを冗長化する際の、適切なリージョンとアベイラビリティゾーンの配置
- DR対策のためのリージョン分散
- バックアップデータの特性や目的に応じた AWS ストレージサービスの選択
「サービスが正常稼働している状態とは何か」を、要素(サービス応答、関連プロセスの稼働、関連インスタンスの稼働、リソース利用状況など)ごとに分析、それぞれの要素の正常動作を定義し、障害発生時のポイントを明確にするような監視設計を行います。クラウドリソース、サービス状態、AWS特有のインスタンス動作を監視し、また、発生した障害状況を監視仕様にフィードバックすることで、穴のない監視を実現します。
障害検知の一次切り分けから二次対応まで、技術者による対応を行うともに、手順書レベルに落とせる復旧作業を自動化することで、迅速・正確な障害対応を実現します。
「サービスの継続性」を担保するために、AutoScalingではカバーできない「アプリケーションレイヤの状態に応じてスケールする仕組み」を別途実装する場合もあります。例えば、特定機能の利用者数や、アプリケーションがどのような処理をしているのか、サービスがどのような状態なのかによって、特定のリージョンやアベイラビリティゾーンを指定してインスタンス数を自動的に増減する仕組みを実装します。
DR対策のためのリージョン配置や、取得データの特性や目的に応じて、S3などのAWS 各種ストレージサービスを適切に組み合わせたバックアップ設計も行います。
- アールワークスは、AWSコンサルティングパートナーです。
- 徹底的な標準化と自動化で高品質の運用を低コストでご提供します。
- 1997年から蓄積した運用ノウハウをもとに＋αをご提案します。
Contactお問い合わせ
お見積もり・ご相談など、お気軽にお問い合わせください。