オンプレ開発とクラウド開発の根本的な違い

これまで受託開発などオンプレミス中心の開発を行ってきた会社が、今はクラウドの時代だからうちもクラウドサービスでも作ってみるかという話をよく聞きます。パッケージソフトウェア開発のベンダーがクラウドに移行することもあるでしょう。今回はオンプレミスの開発しかやったことのないエンジニアがクラウドサービスを開発するにあたって、陥りやすい罠について書きます。

オンプレミスって？

利用者が自前でサーバーを立てて、ITシステムを運用する形態のことです。これに対してクラウドサービスでは、サーバーやソフトウェアをベンダー側で用意してインターネットを介してサービスを提供します。かつては企業向けのシステムはオンプレミス一択でしたが、今では企業でもクラウドを使うのが当たり前になりました。今でもセキュリティを強固にしたいとかカスタマイズを柔軟にしたいといった理由から、オンプレミスでシステムを運用することがあります。

性善説でクラウドサービスを運用すると破産する

まずはこちらの表をご覧ください。これは開発運用面で見た、オンプレミスとクラウドの違いをまとめたものです。

上のような違いがあるために、クラウドサービスの開発経験がないエンジニアが何も考えずにオンプレと同じような意識で開発すると、こんなことが起こります。

• ソフトウェアに脆弱性があったために外部から顧客のデータを抜き取られ、損害賠償が発生する。
• ユーザーがファイルを大量にアップロードしたために、莫大なクラウドストレージの費用を請求される。
• ユーザーがサービス上で違法なコンテンツを発信していたため、削除対応に多大なコストが発生する。
• システムを更新したいが停止するのに事前告知が必要なので年に１回しか更新できない。

これらはいずれも、オンプレミスでは考えなくてもよいことです。ソフトウェアに脆弱性があったとしても、基本的にシステムを使うのは社内の人だけですから、大きな問題になることはまれです。無茶な使い方をして100TBのハードディスクがいっぱいになったとしても、顧客にハードディスクの増設費用を払ってもらえば済む話です。システムはいつでも好きなときに停止してアップデートすることができます。ですがクラウドサービスではそういうわけにいかないのです。

みんな大好きセキュリティチェックシート

クラウドサービスを開発するには、セキュアなシステムを開発するための知識を身につける必要があります。とりあえずはIPAが公開している資料を開発者全員に読ませましょう。

企業では、利用するクラウドサービスが安全なものかを判断するために、セキュリティチェックシートの提出を求める場合がよくあります。各社でフォーマットがばらばらだったり、記入するのにやたら時間がかかることで悪名高いセキュリティチェックシートですが、企業向けのクラウドサービスでは避けて通ることはできません。大抵の場合はサービスを開始したのち、営業がセキュリティチェックシートてのをお客さんが書けっていうんだけどと開発に相談して初めて、まったくチェック項目を満たせていないことに気づいて頭を抱えたりします。

前にこういう記事を書いたので参考にしてみてください。

特に見落としがちなのは例えばこういうのです。作る前に知っていれば、対策もできますね。

• 監査ログを顧客に提供できるか。
• 安全性の低い暗号化方式が禁止されているか。
• データベース、ストレージが暗号化されているか。
• 解約時に適切にデータが削除されるか。
• セキュリティリスクのある機能（メール送信など）を管理者が無効化できるか。

すべての機能に制限値を設けるべき

あなたはチャットサービスを開発しているとします。チャットルーム数、メッセージのサイズ、添付ファイルのサイズ、ルームに入れるユーザー数など、原則としてすべての機能に上限値を設けるべきです。上限値を設けることで、DoS攻撃などによる障害のリスクや、クラウド破産のリスクを避けることができます。ユーザーにデータベースの変なエラーを表示させてしまうこともなくなります。

上限値を設けないのは、それに応じて課金が発生するものだけと考えましょう。

最後は規約で縛る

適切に書かれた利用規約は、システムでは防ぎきれないリスクから守ってくれます。いやがらせや誹謗中傷をシステムで防ぐのはグーグル社には可能かもしれませんが、費用対効果を考えると現実的ではないでしょう。通信量の上限など、目安は決めたいけどいきなり制限すると顧客に迷惑がかかるのであれば、利用規約によってゆるやかに制限を設けることができます。どこかのテンプレから適当に書くのはやめて、利用規約を最後の防波堤と考えましょう。

眠らないサービスを作るには

SLAとSLO

クラウドサービスが障害などでしょっちゅう停まってしまうと、安心して使うことができないばかりか、ユーザーはすぐに解約してしまいます。クラウドサービスの中には、利用にあたってあらかじめユーザーに、こういう品質のサービスを提供しますよという約束を掲げているものがあります。例えばサービスの稼働率は99.9%以上ですよとか、応答時間は5秒以内ですよとか、サポートに問い合わせてから24時間以内に返信しますよとかそういうものです。そういった取り決めとSLA（サービスレベルアグリーメント）とかSLO（サービスレベルオブジェクティブ）とかいったりします。SLAとSLOの違いは、SLAのほうがより厳密に顧客との約束を既定していて、違反した場合は罰金やペナルティが課される場合があります。SLOには法的な拘束力はないですが、こういった基準を目標としてやってますと利用者に示すことができます。

冗長化とスケーリング

オンプレミスの場合は、特定の組織の利用者向けに動かすわけですから、システムのパフォーマンスが問題になることはさほど多くありません。利用が増えたらサーバーを増強くらいはするでしょうが、データベースとWebサーバーを分けて運用したり、Webサーバーを複数台にして負荷分散したりする話にはなかなかなりません。それよりも、顧客が自分たちで運用しやすいようにと単体のWindowsサーバーで動かすモチベーションのほうが強く働きます。しかしクラウドでは複数の顧客向けのサービスを同じインフラ上で提供するのは当たり前ですから、システムの冗長化とスケーリングには気を配る必要があります。具体的な手法は他に譲りますが、障害や負荷上昇によってシステムが停止しないことと、データが失われないことが求められます。すべてのネットワーク、アプリケーション、データを地理的に分散して冗長化するのが理想ですが、どこまでやるかはコストとのトレードオフになります。すぐそこまでやらないにしても、将来に備えてシステムのコンテナ化くらいはやっておきましょう。

無停止アップデート

ちょっとアプリケーションの不具合を直したいだけなのに、何週間も前にユーザーにサービス停止の連絡するのは手間だし、ユーザーにも迷惑がかかってしまいますよね。クラウド開発では、アプリケーションの更新はサービスを停止しなくても行えるようにしましょう。具体的には、ロードバランサーを使ったローリングアップデートや、Blue/Greenデプロイの採用を検討しましょう。

MySQLのオンラインDDL

無停止アップデートで問題になりがちなのが、データベースのスキーマ変更です。MySQLはDDLの実行中に書き込みが行えるオンラインDDLの機能を備えています。

• MySQL 5.6でINPLACE DDLをサポート
• MySQL 8.02でさらに高速なINSTANT DDLをサポート

それぞれのDDL操作で使用されるアルゴリズムをまとめました。カラムの追加やデフォルト値の変更にはメタデータの更新のみで済むINSTANT DDLが使用されることや、主キーの削除やカラムのデータ型の変更にはテーブルコピーが発生することに注目してください。

INSTANT DDLであっても、実行時にはメタデータのロックが発生します。考慮すべき点については、こちらの記事が詳しいです。

おわりに

オンプレミスの開発をやってきたエンジニアがクラウドサービスの開発を担当するにあたって、抑えておくべき事柄をまとめてみました。実は決定的な違いがもうひとつあります。それは、「クラウドサービスの開発に終わりはない」ということです。オンプレミスなら、リリースや納品のタイミングでいったん開発は終了して、また次のバージョンの開発で仕切り直しという感じだと思いますが、クラウドの場合は毎週のように、機能追加や不具合修正のUI改善などのリリースを行うことは珍しくありません。なので開発プロセスそのものを変える必要があります。都度、手作業で回帰テストをしているわけにいかないので、テストの自動化にも取り組まなければいけませんし、操作マニュアルも画面の変更などを柔軟に反映できるような工夫が必要です。オンプレミスの開発に慣れた人だと、マインドを切り替えるのがなかなか大変かもしれませんが、まずはクラウドの開発は根本的に違うものだという認識を持っていただけたらよいかなと思います。