はてなブックマーク

解決したい課題 プログラムコードの不具合や、サーバー/ネットワークの過負荷/障害などが原因で、Webサイトにアクセスできない場合がある。また、大規模なシステム改修時やセキュリティインシデント発生時に、一時的にWebサイトを閉鎖したい場合がある。 このような場合、サイトの訪問者がWebサイトにアクセスできなくなると顧客体験の悪化につながるため、代替となるコンテンツを表示させたい。 クラウドでの解決/パターンの説明 クラウドでは、低コストで信頼性の高いインターネットストレージを用いて静的サイトをホストできるので、Sorry Pageや静的ページだけで構成されたバックアップサイトのホスティングには最適である。 また、クラウドで提供されるDNSサービスで提供されるヘルスチェック機能（指定URLへのアクセス可否の検知機能）を用いると、メインサイトにアクセスできなくなった際に、自動的にバックアップサイ

解決したい課題 写真や動画の共有サイトでは、多数のユーザーからサイズの大きいデータがアップロードされる。アップロード処理はサーバー側の負荷（特にネットワーク負荷）が高く、ある程度の規模のサイトでも、アップロード専用の仮想サーバーが必要になるケースがある。 クラウドでの解決/パターンの説明 アップロード処理をインターネットストレージに任せる。つまり、クライアントから、仮想サーバーを経由することなく、インターネットストレージに直接アップロードする。これにより、Webサーバーでアップロード処理の負荷を考えなくてもよくなる。 実装 Webサーバー（EC2）上で、S3へのアップロードを行うHTMLのフォームを生成する。 アップロードフォームを使用し、ユーザー側からS3へ直接ファイルをアップロードする。 S3にファイル転送を終了した後にフォームに指定してあるURLへリダイレクトされるので、リダイレクト

Sorry! This site is experiencing technical difficulties.Try waiting a few minutes and reloading. (Can't contact the database server: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) (localhost)) You can try searching via Google in the meantime. Note that their indexes of our content may be out of date.

解決したい課題 インターネットストレージは可用性、耐久性が共に高く、サイズの大きなコンテンツやアクセス数の多いコンテンツの配布にはうってつけである。しかし、特定ユーザーにのみコンテンツを配布する場合、作成したアプリケーションの認証の仕組みと連動する必要があり、インターネットストレージだけでアクセス制限を実現するのは難しい。 クラウドでの解決/パターンの説明 インターネットストレージで提供される制限付きURL発行機能を用いると、コンテンツに対して、アクセス元IPアドレスやアクセス可能期間を設定できる。ユーザーごとにURLを発行し、その制限付きURLでのみコンテンツをダウンロードするようにすれば、期限が切れたリンクや異なるIPアドレスを持つ人がアクセスを試みてもダウンロードできない。実質的に特定ユーザーにのみコンテンツを提供することが可能になる。 実装 S3のapitoolやAWS SDKを準

Sorry! This site is experiencing technical difficulties.Try waiting a few minutes and reloading. (Can't contact the database server: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) (localhost)) You can try searching via Google in the meantime. Note that their indexes of our content may be out of date.

解決したい課題 多くのバッチジョブを処理する必要があり、しかもジョブに優先順位がケースが考えられる。 例えばプレゼンテーションファイルをWebブラウザーからアップロードして公開できるサービスで、無料ユーザーと会員ユーザーでサービスレベル（公開までの時間）が異なる場合などが、そのケースに該当する。ユーザーがプレゼンテーションファイルをアップロードすると、システム側で公開するための変換処理などをバッチ処理で行い、変換後のファイルを公開する。そのバッチ処理を会員種別毎に、どのように優先順位付けするかが課題となる。 クラウドでの解決/パターンの説明 バッチジョブの管理にはキューが使える。キューを優先順位の数だけ用意すればよい。ジョブリクエストをキューで管理し、キューのジョブリクエストをバッチサーバーが処理する。 クラウドには信頼性の高いキューがサービスとして提供されており、それを用いることで容易に

解決したい課題 規模の大きなシステムでは、アクセス数などの増大とともに多数のサーバーを増設することになる。その場合、サーバー構築に必要なインストールや設定を一つひとつ手作業で行うのは非常に手間となり、期限内で終わらせることも難しくなる。サーバー構築の自動化を行う方法としてシステム管理ツールを利用する方法もあるが、そこにはコストの問題もある。 クラウドでの解決/パターンの説明 仮想サーバーを起動した際、そのサーバーの目的に合わせてサーバーの内部構成を自動的に構築したいケースがある。特にScale OutパターンやCDP:Scheduled Scale Outパターンを使って運用を自動化したい場合に求められる。こうしたケースではBootstrapパターンが有効だが、外出ししておきたい情報（例えばDB接続先IPアドレス、サーバー名、認識番号など）が多くある場合、このCloud DIパターンを利用

解決したい課題 バッチ処理の負荷分散として、ジョブリクエストをキューで管理し、キューのジョブリクエストを複数のバッチサーバーが並列に処理する方法がある。しかし、用意するバッチサーバー数はピークに合わせた数となるため、ピーク外の時間帯ではバッチサーバーのリソースが余ってしまい、コスト効率が悪くなってしまう。また、予想以上の負荷がバッチシステムにかかった場合、レスポンスが悪くなってしまう。 クラウドでの解決/パターンの説明 従来はサーバーリソースを動的に増減することができなかったので、ピークや許容コストの範囲内でバッチサーバーを用意していた。コスト効率が悪く、想定外の負荷に対応ができないという課題があった。クラウドでは、負荷をモニタリングし仮想サーバーを自動的に増減させる仕組みを備えている。この仕組みを利用することで負荷に応じてバッチサーバーを増減できるようになり、コスト効率がよく想定外の負荷

解決したい課題 システム全部をある地域から異なる地域へ移行したいというケースがある。例えば、オンプレミスのデータセンターから、クラウドへシステムを移行する場合、もしくはクラウドのある地域から異なる地域へ移行したい場合が考えられる。この際、システムのドメイン名を変えることなく、なおかつ、システムを停止することなく、できるだけスムーズに移行したいという要望は大きい。 クラウドでの解決/パターンの説明 ドメイン名を変えることなくシステム全部を移行させるには、DNSサーバーにおいて重みづけラウンドロビンという機能を用い、名前解決する際に既存システムから新システムに切り替える手法がある。最初は新システムに少しだけ振り分け、問題が無ければ、新システムへの配分を徐々に増やしていくことができる。クラウドで提供されているDNSサービスを用いれば、重みづけラウンドロビン設定も容易に行えるため、最小限のDNSサ

解決したい課題 RDBMSの書き込みに対する高速化は非常に重要で、また難易度の高い問題である。スケールアップで実現できる以上のパフォーマンスを出すには、当然、複数のデータベースサーバーを利用することになるが、どのように実現するかは常に課題である。 クラウドでの解決/パターンの説明 複数のデータベースサーバーで書き込みパフォーマンスを上げる方法に「シャーディング」がある。基本的には、同じ構造のデータベースを用意して適切なテーブルのカラムをキーにして分割し、書き込み処理を分散する。クラウドが提供するRDBMSサービスを用いれば、可用性が高く、運用効率もよいシャーディングが可能になる。 実装 AWSのRDBMSサービス「RDS」をシャーディングのバックエンドデータベースに用いれば、可用性と運用効率を高めることが可能となる。 Spiderストレージエンジンを組み込んだMySQLサーバーなどのシャー

解決したい課題 複数サーバーで負荷分散した場合、コンテンツを同期させなければならない。マスターサーバーからスレーブサーバーに定期的に一方向に同期を取るのは簡単だが、定期的な同期では遅延が問題になることがある。また、スレーブサーバーに書き込みが発生するとマスターサーバーや他のスレーブサーバーに反映されないなどの課題は残る。 クラウドでの解決/パターンの説明 このパターンは、複数サーバー間で同じコンテンツをリアルタイムに読み書きできるようにする。共有コンテンツを保管するマスターの仮想サーバーをNFSサーバーとし、スレーブサーバーをNFSクライアントとする。そうすることで、どのサーバーからもコンテンツの更新が可能で、リアルタイムに共有できるようになる。 実装 （手順） NFSサーバーをEC2上に構築する。 共有したいコンテンツをNFSサーバーに配置する。 スケールアウトするサーバー群から、そのN

解決したい課題 あるデータを元に、複数の処理を実行したいケースがある。例えば、画像をアップロードした後に、サムネイル、画像認識、メタデータのスキャンの三つのタスクを実行するなどのケースが該当する。 このような場合、画像アップロードを検知したアプリケーションからそれぞれの処理を呼び出して逐次処理は可能だが、各処理の時間が長い場合、トータルで非常に長くなる。例えば、画像アップロードをWeb 画面から実行した場合にサーバー側の処理が長ければ、ユーザーエクスペリエンスが悪くなる。 また、処理が増えた場合、例えばモノクロ画像作成のタスクを増やしたいような場合は、呼び出し元のプログラムを改修する必要が出てくる。 クラウドでの解決/パターンの説明 処理を呼び出すプロセスから直接各処理を呼び出すのではなく、間にノーティフィケーション（通知）コンポーネントとキューイングコンポーネントを入れることで、非同期か

解決したい課題 世界中のキャッシュロケーションを活用したコンテンツデリバリーのサービスを用いることで、世界中のユーザーに高速にデータを配信することが可能となった。しかし、特定のユーザーにのみコンテンツを配布する場合、利用者を認証する必要があり、そうした仕組みを構築するのは簡単ではない。 クラウドでの解決/パターンの説明 コンテンツデリバリーで提供される「署名付きURL認証機能」を用いる方法がある。ユーザーがコンテンツをダウンロードするためにWebサイトにアクセスする際に、あらかじめ設定しておいた「アクセス元IPアドレス」「ダウンロード可能期間」「アクセス元地域」等に適合した場合のみ、「署名付きURL認証機能」を発行すれば良い。より高い精度での特定ユーザーへの配信が可能となる。 また署名付きURL以外にも、クッキーに対して署名を付与する「署名付きクッキー認証」を利用することもできる。 実装

解決したい課題 複数システムで処理を連携させて逐次的な処理（例えば、画像処理の場合、画像のアップロード、保存、エンコーディング、サムネイル作成、などの逐次作業）を行う場合、システム同士が密に結合しているとパフォーマンス面でボトルネックが発生しやすい。また、障害時の復旧作業が煩雑になってしまう。できるだけシステムを疎結合にすることがパフォーマンスやメンテナンスの面で好ましい。 クラウドでの解決/パターンの説明 システムを疎結合にする一つの方法は、システム間をキューでつなぎ、ジョブの受け渡しをメッセージの送受信で行うことである。こうすれば非同期でシステム連携できる。この方法の場合、メッセージを受け取って処理する仮想サーバーの数を増やして並列処理できるため、ボトルネックを解消しやすい。また、仮想サーバーに障害が発生しても、未処理のメッセージはキューに残っているので、仮想サーバーが復旧次第、処理の

解決したい課題 システム構成をセキュアにするため、インターネットに公開する必要がないサーバーは、インターネットとの直接的な通信ができないネットワークセグメント（プライベートサブネット）に配置する構成にする場合が多い。 この場合、プライベートサブネットから外部へのアウトバウンド通信はNATサーバーやプロキシーサーバーを経由するが、このサーバーに障害が発生すると、プライベートサブネットのサーバーからアウトバウンド通信が行えなくなり、システム全体の障害につながる。このため、単一障害点（SPOF）にならないように、冗長化が必須である。 クラウドでの解決/パターンの説明 NATサーバー/プロキシーサーバーの冗長化を行う。障害発生時の迅速なフェイルオーバーと、より高い冗長性の確保のため、複数のデータセンターに複数のNATサーバー/プロキシーサーバーを配置し、単一障害点とならないようにする。 また、障害

解決したい課題 複数の同機能のサーバーを用意して冗長構成を採ることは一般的だが、フェイルオーバー時の接続先の切り替えはさまざまな方法が存在する。 同一セグメント（サブネット）のネットワーク内なら仮想IPアドレスの付け替えなどで比較的容易に実現できるが、セグメント（サブネット）、あるいはデータセンターを越えたサーバーへのフェイルオーバーでは、その方法での実現は難しくなり、他の方法を考える必要も出てくる。 例えば、DNSを用いた名前解決での切り替えなどはよく使われる。しかし、「ダウンタイムをTTLより短くできない」、「DNSサーバーというコンポーネントが増えてしまう」などのデメリットを考慮する必要がある。 クラウドでの解決/パターンの説明 セグメント（サブネット）やデータセンターを越えたサーバーへのフェイルオーバーは、クラウド環境でも同様の問題を抱える。 しかしクラウドによっては、複数データセ

クラウドの特性を考えると、これまでのシステムアーキテクティングと異なった視点が必要となる。それをクラウドアーキテクティング原則として整理している。 できるだけサービスを利用 例えばAmazon S3というインターネットストレージのサービスを考えてみる。これは耐久性が高くて便利なオブジェクトストレージなので、Amazon EC2を使って似たような機能を実装するよりも、S3を使った方がいい。キューイングにしても、Amazon SQSというサービスがあるので、EC2にキューイングソフトを入れて自分で管理するよりも、このサービスを使った方が良い。すでに存在しているサービスのメリット/デメリットを正確に理解し、使いこなせることが大事。利用者としては、車輪の再開発はしないほうがいい。 机上実験よりも実証実験 机上実験に終始して「このシステムでこの負荷だと、インスタンスタイプはどれを何台使えばいいのか」

解決したい課題 データは何よりも大切なものとして「安全」に扱わなければならない。そのためには、データをバックアップすることが欠かせない。具体例としては、テープを用いてバックアップしたデータを別拠点に保存しておく方法がある。しかしテープバックアップはテープ交換や保管などにコストが掛かかるうえ、これらの作業は自動化が困難である。高価な装置を購入することで半自動化することは可能だが、それでもテープの容量は有限のため補充が必要になり、完全な自動化は困難である。 クラウドでの解決/パターンの説明 クラウドでは安全で容量制限がない「インターネットストレージ（Webストレージともいわれる）」を比較的安価に利用できる。 ある瞬間のデータを複製したバックアップを「スナップショット」というが、これはクラウドではよく用いられる概念である。クラウド上で仮想サーバーのデータ（OS含む）やその他のデータをインターネッ

解決したい課題 インターネットストレージは一般的に、読み込みに対するキャパシティーやデータの耐久性が非常に高い。しかし、冗長性を保つために複数ローケーションに書き込んでいるほか、HTTPプロトコルでクライアントと通信しているので、書き込み速度が比較的劣るという性質がある。大量データをインターネットストレージに書き込む場合に、パフォーマンスが問題になることがある。 クラウドでの解決/パターンの説明 クライアントからインターネットストレージに直接データを転送するのではなく、仮想サーバーでデータを受け、その仮想サーバーからインターネットストレージへ転送する。クライアントから仮想サーバーへの転送では、HTTPよりも高速なプロトコル（例えばUDPベースのプロトコル）を使うことができる。また、小さいサイズのファイルが大量にある場合は、クライアント側で一度アーカイブし、仮想サーバーに転送後に解凍してイン

解決したい課題 システムにとって重要なデータを守る基本的な方法はデータベースに格納すること。さらに最近ではデータベースのレプリケーション機能を使うことも増えている。レプリケーションは比較的よく行われるが、従来はコストの関係上、一つのデータセンター内に閉じることが多かった。しかしながら東日本大震災のような大規模な災害が現実に起こり、データセンターごと損傷を受けるケースを想定しなければならない。 クラウドでの解決/パターンの説明 地理的ロケーションをまたいだレプリケーションを行うパターン。このパターンによりデータロストを防ぎ、データアクセスの可用性を担保する。クラウド以前からもあったパターンであるが、クラウドを用いることで安価に複数の地理的ロケーションを利用できるようになり、現実的な選択肢となった。 実装 AWSには「リージョン」「アベイラビリティーゾーン（AZ）」という考え方がある。リージョ

解決したい課題 マシンイメージからサーバーを作成する方法、すなわちStampパターンの適用に際し、どの程度の頻度でマシンイメージを取得するかは運用効率に対する課題として、しばしば議論となる。 Stampパターンでは、ミドルウエアからアプリケーションまですべてが設定済みで、立ち上げるだけでそのまま動くマシンイメージを作成することもできる。この場合、仮想サーバーの起動は非常に早いが、ミドルウエアの一つをバージョンアップしなければならなくなった場合や、アプリケーションの設定に変更が入った場合、マシンイメージを再度作成し直す必要が出てきてしまう。 クラウドでの解決/パターンの説明 クラウドではマシンイメージの作成が容易にできるだけでなく、起動時にパラメータを設定できるものがある。この機能を利用してサーバー構成に必要なパラメータを渡すことで、サーバーを起動する際に必要な設定をサーバー自ら取得し、イン

Sorry! This site is experiencing technical difficulties.Try waiting a few minutes and reloading. (Can't contact the database server: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) (localhost)) You can try searching via Google in the meantime. Note that their indexes of our content may be out of date.

Sorry! This site is experiencing technical difficulties.Try waiting a few minutes and reloading. (Can't contact the database server: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) (localhost)) You can try searching via Google in the meantime. Note that their indexes of our content may be out of date.

Sorry! This site is experiencing technical difficulties.Try waiting a few minutes and reloading. (Can't contact the database server: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) (localhost)) You can try searching via Google in the meantime. Note that their indexes of our content may be out of date.

Sorry! This site is experiencing technical difficulties.Try waiting a few minutes and reloading. (Can't contact the database server: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) (localhost)) You can try searching via Google in the meantime. Note that their indexes of our content may be out of date.

Sorry! This site is experiencing technical difficulties.Try waiting a few minutes and reloading. (Can't contact the database server: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) (localhost)) You can try searching via Google in the meantime. Note that their indexes of our content may be out of date.