コンクリートファイブジャパン岩本です。


先日、弊社CTO佐々木が「専用サーバー、VPS、クラウドの比較」を書きましたが、

なぜあえてパフォーマンスでは費用対効果が一番悪いAWSをこのconcrete5 Japan, Inc.のコーポレートサイトのインフラに選んだのか？


理由は「楽をしたいから」です。


もちろん「楽をしたい」だけでは、ただの怠けですが、システムの運用負荷が下がれば、（レンタルサーバーであれば）サーバーの月額費用などのサーバー実費以外の「運用コスト」を下げることができ、トータルコストの削減ができます。

「運用が楽になる ＝ 内部的な人件費を抑えられる」という事です。

また、弊社のように少人数の会社では、極力運用コスト（ヒューマンリソース）を抑え、その空いたリソースをわさび様をモフモフする時間に別業務に割り当てることで、会社全体の利益の最大化が図れます。

結論から言うと弊社では今回のAWSの利用で運用コストだけでも年間30万円程度の削減を見込んでいます。

AWSを選べば、具体的にどのような楽ができるのか?を列挙しました。（あくまでも私見ですのでご容赦ください）

  • DBの運用が容易（Amazon RDS）
  • ストレージの運用が容易（Amazon S3）
  • インスタンス（Amazon EC2）を極力シンプルに構成にできる
  • 将来的、突発的に負荷が上がった際の対応が容易

では、順に見ていきます。

の前に、わさび様のお食事風景をご覧ください。ちなみに、わさび様はリンゴが大好物です！


DBの運用（Amazon RDS）

弊社サイトでは、データベースにAmazon RDS（MySQL）を利用しています。

concrete5ではコンテンツのデータをDB（MySQL）に保存するため、DBの稼働が必須となります。

Amazon RDSとは、MySQLやPostgres、Oracleなどが利用できるマネージドサービスです。

マネージドサービスとは、AWSにて各インスタンスの管理が自動化されたサービスです。

以前であれば、サーバーにOSをインストールし、MySQLをインストールし、OS・MySQL・ネットワークなど、各レイヤーにて稼動を監視した上でMySQLを利用していました。

バックアップも、スクリプトもしくはパッケージソフトなどを別途用意し、バックアップの実施を行い・バックアップの成否を監視する必要がありました。

しかしマネージドサービスであれば、MySQLの稼動がAWS側で管理されており、利用者はMySQLを利用することのみに集中できます。

データベース（MySQL）のフルバックアップもRDS側にて定期的に自動で取得されます。合わせて、5分間隔で所定の状態へデータベースを復元する機能（Point In Timeリカバリ）もあります。

MySQLのパラメータも元々Amazon側で最適化されており、一般的な利用ではチューニングが不要です。さらにマネージドサービスですが、より最適値へとチューニングをすることも可能です。

このように、RDSを用いることで従来のDB運用に比べ圧倒的に容易になります。

また、RDSを用いれば、バックアップストレージの手配が不要になり、上記に書いたようなバックアップスクリプトやパッケージソフトも不要になることから、よりミッションクリティカルなシステムであるほど純粋なコスト（利用費）の削減が図れます。



ストレージの運用（Amazon S3）

以前、こちらや、こちらの記事にも記載した様に、Amazon S3を利用することで、ストレージのキャパシティプランニングが不要となり、バックアップも不要となります。

合わせて、concrete5の静的コンテンツと動的コンテンツの分離をすることで、Webサイト全体のパフォーマンスの高速化が図れます。

S3の利用でもRDSと同じように、バックアップストレージの手配が不要となります。

また、S3の課金体系はストレージの実利用分のみのとなります。従来の大容量ストレージであれば、利用していない空き領域へも利用料を支払っていました。



インスタンス（Amazon EC2）を極力シンプルに構成

concrete5はPHP上で稼働します。

AWSでは、残念ながら現時点でPHPを提供するマネージドサービスはありませんが、インスタンス（EC2）の構成を極力シンプルにすることで、運用の簡略化が図れます。

データベース（MySQL）はRDSに。ファイルの保存先はS3に。と、EC2ではPHP（とNginx）が稼働するだけとしています。

デザインやプログラムのデプロイはgit経由とすることで、オリジナルはgitリポジトリに存在し、システムの復元や、2台目以降のサーバー追加は、マシンイメージにgitリポジトリからデプロイをするだけでシステムの構築が行え、EC2での日々のバックアップは不要としました。

このようにEC2内にあるデータは改変がかからない物へとする事で、将来的なAutoScaling（自動的な高負荷対応）への対応へも容易に行えるようにとしました。

EC2内のソフトウェア構成をシンプルにし、EC2の必要スペックを下げることで、コストの削減も期待できます。

さらにEC2のパフォーマンスをより効率的に発揮させるため、WEBサーバーにはNginx、PHPも最新のPHP7を利用し、HTTP/2プロトコルにも対応しました。

concrete5をNginx＋PHP7＋HTTP/2環境で動かしたお話は、また別の機会により詳しく書かせてもらえればと思います。



将来的、突発的に負荷が上がった際の対応が容易

AWSに限らず一般的なクラウドサービスであれば、各サービスをスポット（時間単位）での利用が可能です。

将来、または突発的に負荷が上がった際も、各インスタンスのスケールアップ・スケールアウトが容易に行えます。

負荷が下がった際には縮退も容易で、契約のコミットメントも不要なため、余剰なコストを抑えることができます。


ちなみに、負荷が下がり切ったわさび様が、こちらになります。


AWSには今回紹介したサービス以外にも、ビッグデータ解析のための Amazon Redshift や、全文検索を行うための Amazon Cloudsearch など、数多くのサービスが存在します。

今後システムの規模・用途が拡大する際にも、AWS環境にシステムを置くことで、容易にAWSのサービス群と連携できることも魅力の一つです。



まとめ

従来の環境でインフラに割く労力に比べ、この様にクラウドサービスをうまく利用することで、日々発生するインフラの運用作業の軽減が図れます。さらにクラウド環境を最適化することで、ランニングコスト自体の削減も可能です。


ただし、今回はAWSについて書きましたが、突発的な高負荷に対応出来るシステム、可用性の高いシステムなど、システムの用途、利用者によって最適な構成は様々です。


弊社には、インフラだけではなく、システム開発、WEBサイト運営、そしてもちろんconcrete5の専門家が在籍しています。

「じゃあ何がいいの？」

とお悩みであれば、各分野の専門家が協力しインフラだけではない広い視点で、より最適なシステムをご提案します。

まずは弊社のインフラコンサルティングサービスにお気軽にご相談ください！