Q1：Herokuの性能が気になります……本当に企業システムで使えるの？

HerokuはAWS（Amazon Web Services）の米国東リージョン上で稼働しているため、通常のWebアプリケーションと同じように構築してしまうと、地理的な問題からレイテンシ（遅延）が大きくなってしまい、性能が落ちてしまいます。

それを回避するために、CDN（コンテンツデリバリネットワーク）とAjaxを活用して、うまくレイテンシを抑えるようにする必要があります。

CDNを活用したコンテンツキャッシュ

CDNを活用することにより静的なコンテンツを最寄りのエッジサーバから取得できるため、画像データや動画、CSS/JavaScriptなどのファイルを毎回オリジナルサーバ（Heroku）から取得する必要がなくなります。

実際にYahoo! JAPANを例にしてCDNの効果を検証してみると、受信データ量はサイト全体が約200kbyte。この内、画像データやCSS/JavaScriptファイルを除いたHTMLだけのファイルサイズは約30kbyte（註1）となります。CDNを利用して、すべての静的コンテンツをエッジサーバから取得できる場合には、オリジナルサーバから取得するデータは全体の15％弱程度まで抑えることができます。

ただし、気をつけなければならないのは、CDNではオリジナルのデータが変更されてから時間差でキャッシュが更新されるため、削除・更新が頻繁に行われるデータには不向きであることと、キャッシング時間が決まっているためアクセスの少ないデータでは効果が出にくく、全ての静的コンテンツがCDNの恩恵を受けられるわけではないことです。

註1：データ量はhttpwatchを利用して計測

Ajaxを活用したリクエストデータの局所化

CDNは主にダウンロードする静的コンテンツのデータ量の削減を目的としていましたが、特に海外にサーバがあるようなWebアプリケーションの場合には、回線速度等の問題でそれだけでは十分な性能を出せないケースがあります。

Herokuが稼働する米国の場合は、日本国内からのアクセスに限れば実務で困るくらい遅くなることはありません。しかし、他の国での利用も想定したグローバルなシステムの場合、ロケーションによっては回線の実速度が数キロバイト程度まで落ち込んでしまうケースがあります。実際にグローバル展開を行うシステムを構築した際に、こういったレイテンシに伴う性能の問題に苦しめられるケースがありました。

これを回避するには、Ajaxを活用して通信するデータ自体を絞込み、通信コストを削減するとともに、非同期処理を活用して体感的に速度を早くすることが効果的です。

上記のようにすることでHTTPリクエストを画面全体（HTML）ではなく、一部（必要なテキストデータのみ）に抑えることができるので、通信コストを削減できるようになります。

また、データ量の多い画面の場合には非同期で画面の項目がレンダリングされるため、視覚的に早く見せることが可能で、利用しているユーザーの体感速度を早めることができます。

Q2：Heroku上で構築したアプリケーションはForce.comや社内システムとどう連携させるの？

Heroku上のアプリケーションとForce.comを連携させるには、SOAP、RESTでのHTTPをベースとした方法と、ActiveSalesforce（Ruby）、JPA（Java）を利用した方法があります。

ただし、HerokuのHTTP接続には制約があるため、Force.comとの連携にはActibeSalesforceとJPAを利用する方法をお奨めします。

社内システムと連携させる場合にもSOAP、RESTを利用した連携が可能ですが、HerokuのHTTPの接続制限から、まとまったデータの連携についてはHeroku PostgresやAWSのAmazon RDSといったDatabase as a Service（以下DaaS）を利用したデータベースでの連携を行います。

余談になりますが、Heroku PostgresとAmazon RDSのどちらを使った方が良いのかといった質問を受けることがあります。自動バックアップ、メンテナンスフリー、接続の暗号化（SSL）と、双方が持つ機能にはあまり差が無いので判断が難しいところだと思います。

ただ、格納できるデータのサイズは、Heroku Postgresが2TBなのに対してAmazon RDSは1TBという大きさの違いがあります。また、RDSはリードレプリカが利用できるため、他のシステムへ読み込み専用のデータベースを提供できるなど、機能面でも若干異なっています。 基本的にはHeroku Postgresの使用を前提として、外部システムや他のAWSとの連携要件次第で、Amazon RDSを選択するのが良いと思います。

Q3：Herokuを使った場合にセキュリティが心配なのですが…

Herokuはインターネットを利用して既存システムと連携させる必要があるため、ハッキングなどのセキュリティ面が気になると思います。実際、Herokuに限らず、パブリッククラウドを導入するケースではセキュリティに関する承認に多くの時間を費やすことが多く、重大な関心事だと感じています。

今回は、その中でも実際の導入時に問題となりやすい認証とデータ漏洩という2つの観点からセキュアなシステムを構築する上でのポイントを解説します。

認証

不特定多数のユーザーのみを対象としたWebシステムやFacebookなどのソーシャル系の専用アプリケーションの場合には、OpenIDやOAuthを利用することが多いため、独自で認証を考える必要はありません。

しかし、社員や顧客などの限られたユーザーに限定して提供したいようなWebシステムの場合には認証処理が必須となります。その際、社内で管理されているユーザー情報を基にして認証しますが、それらの情報は個人情報を含むため、単にクラウド上に移管させるだけではリスクが高くなってしまいます。

このようにオンプレミスとクラウドを連携させてIDを管理する必要があるときは、SAMLやSWT（Simple Web Token）に対応したFederation Serverを導入し、安全に認証と属性（ユーザー情報）を連携させることで、ある程度リスクを回避することができるようになります。

SAMLやSWTを利用して連携することで、必要な属性のみが連携されるため、Heorku上で構築したアプリケーションでは個別にユーザー情報を管理する必要がありません。

ただし、上記の構成では社内のID管理（LDAP等）に登録されたユーザーしか使用できません。これに加えて、社外のユーザーにもインターネット経由でアプリケーションを提供する場合には、社内のID管理に利用ユーザー全員を登録した上で、Federation ServerをDMZなどのインターネットからアクセス可能な場所に配置しなければなりません。

IDを管理していない社外ユーザーも対象としたい場合やFederation ServerをDMZ上に配置したくない場合には、Microsoft が提供しているMicrosoft Azure Appfabric Access Control（ACS）を組み合わせることで、既製のIdP（アイデンティティプロバイダ）やクライアント独自のFederaion Server（インターネットアクセスが可能な場合のみ）に登録しているユーザーとの連携を簡単に実現できます。

ACSを併用することで、社内でID管理されているユーザーのほか、不特定多数ではない、他のソーシャルサービスに登録されているユーザーにもID管理無しにWebアプリケーションを提供することが可能となります。

データ漏洩

Herokuではアプリケーションもデータベースもクラウド上に配備されるため、データの漏洩に対する配慮が必要となります。特に既存システムの社内情報と連携させる場合には、セキュリティ管理は重要な課題として対策しなければなりません。

データ漏洩を防ぐには、通信の暗号化とデータの分散配置という2つのアプローチから考える必要があります。

Herokuでの通信の暗号化はSSLを使うことが前提となります。Q2の構成でSOAP、RESTで連携させる場合にはHTTPSを利用し、DaaSであるHeroku Postgres、Amazon RDSではSSLサポートがされている（5月17日時点ではMySQLのみ）ので、クライアント接続、ODBC/JDBC接続時にSSLで接続することで通信の暗号化が可能です。

データの分散配置とは、コードと値を別々のデータストアに格納するようにデータ設計を行うことです。例えば社員情報の場合には、データベース上には社員番号でデータを保持させ、HerokuのaddonであるMemchached（分散キャッシュ）やMogoDB（KVS）に社員マスタを保持しておいて、1つのデータストアに関連も含めたすべてのデータを持たせないようにします。また、そもそもの設計としてマスタ関連は最低限必要なもののみを持たせるようにすることも大切です。