ECサイトのログ・メトリックスの集約まとめAWSへの移行と移行後の運用のポイントを解説する「AWSに移行した環境の最適化のススメ」の連載です。前回の「AWS最適化の進め方」では、AWSを最大限に活用するための重要なポイントをご紹介しました。今回の「AWS最適化の具体例」では、本連載でご紹介したことを踏まえて、どのように最適化を進めていくのか具体例とともに解説します。Webアプリケーションのバックエンドの冗長化リフト時の状況ユーザーが自身で撮影した写真をアップロードしてシェアするWebアプリケーションをオンプレミスで運用していたA社。Active/Standbyの2台構成のLAMP環境をそのままAWSにリフトしました。Route53のヘルスチェックをトリガーに、S3上にあるSorryページに復帰先を自動で切り替えるような構成にしています。ちなみにS3はオブジェクトストレージサービスですが、静的なウェブサイトをホスティング出来る機能があります。ActiveからStandbyへは、lsyncとrsyncを利用しコンテンツを同期しています。データベースはMySQLのMaster/Slave構成となっており、基本的にはActive/Standbyに同じものが載っている状態です。Activeが完全に落ちてしまった場合は、StandbyのMySQLをMasterへ昇格し、DNSをStandby側に手動で切り替えるという運用を行っています。ユーザー数の増加に伴いリソースが枯渇した際は、メンテナンス時間を設けて手動でスケールアップを行っています。ビジネス要件の変化と課題ユーザー数の増加に伴い、サーバーリソースが枯渇しSorryページの表示が頻発するようになりました。そのたびにスケールアップのメンテナンスが発生するため、社内からメンテナンス時間を設けずにユーザー数増加に対応したいという要望が出てきました。(ELB)・EC2・RDSを利用した構成への変更を検討していましたが、ユーザーからアップロードされた画像ファイルを2台のEC2間で共有する最適な方法が見つからず、断念していました。画像ファイルをS3に格納する案も挙がりましたが、レイテンシーやアプリケーション自体の改修がボトルネックとなり、採用は難しいと判断しました。他にもNFSサーバーを立てる案がありましたが、NFSサーバーが単一障害点となってしまうため、こちらの案も不採用となりました。EFS)というサービスの導入を行いました。EFSはマネージド型の共有ファイルストレージサービスであり、NFSv4に対応しています。2018年7月に東京リージョンでも利用可能となりました。ストレージ容量は自動で拡張し、スループットやIOPSもファイルシステムの拡張に併せてスケールします。EFSに保存されたファイルは複数のアベイラビリティーゾーンに複製されるためファイル消失の可能性は極めて低いです。EFSの導入によって2台のEC2間のファイル共有の課題を解決することができました。EFSのスループットは先に記載した通り、自動でスケールしますが、格納されているファイルの合計容量が少ないとスループットが上がらないままとなってしまいます。EFSに置いてしまうとログイン速度が遅くなる問題が発生しました。ELBのセッション維持機能を使うことで2台のEC2間のログインセッション共有の課題を回避しましたが、これだとセッションの偏りが発生する場合があります。ElastiCacheにセッション管理を移行し、2台でセッションを共有する構成にすることを検討しています。Scalingの導入も行う予定です。コーポレートサイトと会員サイトの統合リフト時の状況コーポレートサイトと会員サイトの2サイトを運営しているB社。コーポレートサイトは1台構成のオンプレミス環境からAWSへリフトし、EC2シングルインスタンスで稼働しています。Balancer(CLB)・EC2・RDSのLAMP環境で、複数のアベイラビリティーゾーンを利用した冗長構成になっています。会員サイトはSSL化されていますが、コーポレートサイトはSSL化が出来ていない状況です。ビジネス要件の変化と課題ブランディング戦略の一環として、コーポレートサイトと会員サイトを同一ドメインかつ全ページSSL化にしたいという要望が社内から出てきました。コーポレートサイトは複数の制作会社に外注していた経緯があり、リダイレクトルールがバラバラでブラックボックス化しています。そのためHTTPからHTTPSへのリダイレクトは、このリダイレクトルールを整理しなければ出来ない状況となっていました。最適化の方法この状況を解決するため、まずはマネージド型のL4ロードバランサーであるCLBを使い、リバースプロキシを立てることを検討しました。CLBはアベイラビリティーゾーンをまたいだ振り分けが可能で冗長化されているため、VIPの切り替えを意識しなくてもよいというメリットがあります。高負荷時には自動スケールができ、SSLの終端が可能です。CLBとリバースプロキシ2台を立てることで1つのFQDN内でウェブサイトを公開するかつ、リバースプロキシでHTTPからHTTPSへのリダイレクトを行う構成を考えました。この構成だとEC2が増加してしまうため、AWS利用料も管理・運用コストも上がってしまいます。Balancer(ALB)を導入することです。ALBは2016年8月にリリースされたマネージド型のL7ロードバランサーで、高機能かつ機能が追加され続けていることが魅力のサービスです。2019年3月にはパスベース、ホストベースでのルーティングに加えHTTPヘッダーやクエリ文字列によるルーティングも可能になりました。HTTPからHTTPSへのリダイレクトやソーリーサイトのホスティングも可能で、SNIもサポートしており、一つのALBの中で複数のSSL管理もできます。コーポレートサイトと会員サイトのインスタンスをターゲットグループで囲み、ALBでアクセスを受け、パスレベルでそれぞれのターゲットグループに振り分ける構成にすることで、要件を満たすことができました。残課題と今後のシフト予定コーポレートサイトがシングル構成のままになっているため、次のステップでは冗長構成にすることを検討しています。ALBの例のように、AWS上のサービスは随時機能拡張されていくため、過去導入を検討した時の課題点も、いつの間にかクリアされているということがあります。そのため、既に知っているサービスであっても、仕様を適宜確認することが重要と言えます。ECサイトのログ・メトリックスの集約シフト前の状況ECサイトをAWSで運営しているC社。CloudFrontを導入し、静的ファイルのキャッシングを行っています。Scalingも設定しており、インスタンス数の増減でアクセスの増減に対応をしています。CloudFrontとALBのアクセスログはS3に収集しています。過去にデータベースのクエリ滞留がボトルネックとなっていたことがありますが、これは読み込み専用のレプリカ(リードレプリカ)をRDSで作成し、読み込みのクエリをリードレプリカに向けることで解消しました。課題EC2でヘルスチェックがNGとなり、ターミネートする事象が頻発するようになりました。CloudWatchで状況を確認しましたが、標準メトリクスのCPU使用率は異常値を示していませんでした。ターミネートしたEC2インスタンスの詳細なメトリクスやログは設定をしていなかったため、原因の調査が出来ない状況になっていました。CloudWatchでは特に設定を行わず標準で取得できるメトリクスが限られています。自身で設定をしなければ、メモリやディスクの使用率などが取得できないのです。Logsというマネージド型のログ管理ツールを導入することにしました。エージェントが利用可能となっています。導入もエージェントのインストール後ウィザード形式の質問に回答するだけなので簡単です。Logsの導入で取得できるメトリクスを増やした結果、今回のEC2がターミネートする事象は、メモリの枯渇が原因と判明しました。DBに負荷を掛けているようでした。DBを拡張することで解消することができました。Logsに溜まっているログデータを定期的にS3へ蓄積し、解析基盤であるRedShiftにロードし、ユーザーの行動履歴を分析する機能を実装することを検討しています。まとめAWS上でシステムを運用する上で重要な「最適化の継続」について3つの具体例をご紹介しました。ビジネスの要件が絶えず変化していると同時に、AWSのサービスも拡張しつづけています。そのため、移行したら終わりではなく、常に最適な状態を模索し続けることがAWS運用のポイントです。「最適化の継続」には、自社が未評価のサービスや機能を評価できる「環境と文化」が必要です。出来る限り本番と同等のステージング環境を用意し、いつでも構成変更の評価ができる環境を整えること。した環境の中で、トレードオフの際に残課題としたものも、定期的にレビューする習慣をつけること。必要であればいつでも評価をしてもよいという文化と予算を用意すること。この3点を整えることが、最適なAWS環境の運用のために重要と言えるのではないでしょうか。本記事が皆様のAWS運用の手助けになると幸いです。※本記事の内容につきましては2019年1月時点での情報です。AWSの運用を最適化したい方にオススメ!ミズノ様がAWS運用を最適化しコストを3割削減した秘訣MSP事業者に運用を任せっきりになっていたため、AWSの構成や設定・稼働状況などがブラックボックスに...。そんな状況の中、運用管理コストを最適化した方法をご紹介します。