サーバーレスへの道（3） ~アウトソーシング~

サーバレスアーキテクチャを選ぶ時に考える事

前回は「アーキテクチャとセキュリティ」についての記事を書きました。今回は、サービスをクラウドにアウトソースする影響について調べていきたいと思います。

アウトソーシング

サーバーレスの核となるコンセプトは、サービスプロパイダに管理をアウトソースするということです。IT業界では、アウトソーシングするということはそう新しいことではありません。もうすでにデータセンターの管理をAWSやAzureに任せているでしょう。

クラウドサービスを利用するということは技術的な面が見られますが、全てをアウトソースするというのはビジネス的な面があるのです。サービスをアウトソースする前に、2つ考えることがあります。

そのサービスは、競争上の優位性があるか？
そのサービスは、ビジネスにおいて非常に大事であるか？　言い換えると、サービス障害は大きな混乱を招くか？

この2つの質問は、アウトソース検討するためのマトリクスのベースとなります。質問に対する答えがそれぞれ No と Yes であるならば、サービスをアウトソースすべきでしょう。

アプリケーションを実行するのに多くのタスクが必要とされますが、多くは競争上の優位性をもちません。これが理由でクラウドは選ばれているのです。

サーバーレスでは、今まで以上にアウトソースを行います。伝統的なアプリケーションでは、パッチ当てやスケーリングといった運用のタスクが必要でした。しかしサーバーレスではフルマネージドサービスを利用するため、責任分界点や、障害対応、サポートとの向き合い方、そしてコストが変わるのです。

責任

クラウドプロパイダはよく共有責任モデルについて語ります。責任共有モデルでは、クラウドプロパイダはサービスの運用とセキュリティに責任を持ち、ユーザはそれらのサービスをどのように使うかについて責任を持ちます。

フルマネージドサービスを使用するということは、インフラ部分のコントロールをよりクラウドプロパイダに渡すということであり、プロパイダはサービスのセキュリティ確保とスケーラビリティを引き受けることになります。これによってユーザとしてはインフラの管理を行わず、アプリケーションの開発に専念することができるのですが、完全に責任から逃れられるわけではありません。

ユーザは、サービス提供先のカスタマーに責任があります。カスタマーとしては、どのクラウドプロパイダが利用されているかについて興味がありません。サービスの裏側のコスト、スケーラビリティ、またセキュリティについてさえも興味はありません。しかし、使用しているサービスのパフォーマンス、セキュリティ、またはサービスがどれだけ安いかについては興味があるのです。大事なこととして、カスタマーは障害時に説明を求めます。たとえ背後にあるインフラがフルマネージドであっても。

障害

どんなサービスも完璧ではありません。いずれかの時点でクラウドプロパイダは、バグあるいは機能停止となります。最近私の利用しているクラウドの一つに障害が起き、友人の Toby Hede はこんなツイートをしました。

https://twitter.com/tobyhede/status/786087745764589568

障害が発生してしまうと、カスタマーとは問題についてコミュニケーションをとる他なく、クラウドプロパイダが解決するまで待つしかありません。先程書いたクラウドの障害の件は、すばやく問題が解決されました。ちゃんとしたクラウドプロパイダを選ぶことの大切さを再認識した障害でした。

どのクラウドを選択するかを考える時、障害について考えましょう。この3つを考えてみてください。

サービスのSLAは何であるか？
サービスの稼働時間が公開されているか？ステータスページはあるか？
障害にクラウドプロパイダがどのように対応するか？

答えがあれば、クラウドプロパイダが素早く効果的に障害に対応してくれると自信がもてるでしょう。答えが出ない場合、ほかのクラウドを選んだほうがよさそうです。

障害許容力（Resilience）

あなたが運用するサービスに対する責任は、完全にあなた自身にあります。その結果、全てをクラウドプロパイダに頼り切るということはできないでしょう。

使用しているクラウドがサービス終了となったり、あるいはクラウドサービスの質が下がってきたらどうしましょう？別のクラウドを選ぶか、自分自身で機能を実装する必要があるでしょう。

もし必要なら、どれくらい簡単に他のクラウドに移行することができるのでしょうか？この際にベンダーロックインが問題となります。システムがクラウドに依存していればいるほど変更することが難しくなり、クラウドプロパイダが自身のサービスにもたらすリスクを増やします。

どの組織でもデータは重要な資産であり、データのロストに責任があります。さてクラウドプロパイダがデータをロストした場合、どのように対応しましょう？どれだけ早くバックアップを取得できるでしょうか？クラウドにデータを格納する前に、これらの課題を考えましょう。

サポート

クラウドを利用すると、いくつかの問題については自分自身で解決ができないことがあります。簡単な質問であったり、サービスに影響があるクリティカルな問題があります。クラウドに問題があった！who ya gonna call?

[caption id="attachment_51710" align="aligncenter" width="281"] 1oqgpk3iri_lvcsjniijc7g “Ghostbusters” — wikipedia[/caption]

クリティカルな問題があった時、クラウドプロパイダは早急に対応してくれるでしょうか？どのレベルでサポートしてくれるのでしょう？サポートの品質というものは、フルマネージドサービスの重要な一面であるのです。

コスト

サーバーレスは費用対効果が高い手法でしょう。AWS Lambda を利用して、プロダクションのワークロードを $0 で動かしている人がいると聞いたことがあります。コストメリットは、サーバを利用量に応じて動かせる点にあります。

FaaS (Function-as-a-Service)プラットフォームを利用したワークロードは、全て安くなるわけではありません。FaaSファンクションを24時間毎日動かしていれば、サーバ上で同じコードを実行するより高くつきます。とはいえ、ほとんどのワークロードがこのカテゴリーに分類されるわけではありません。

その他のコストの変化を数字で表すことは困難です。フルマネージドサービスを使用することで、開発にかかる時間を節約することができます。A Cloud Guruでは、クラウドを利用することで開発メンバーの数を抑えることができています。とはいっても全てがうまくいっているわけではありません。

サーバレスのような熟していない技術を利用するには、時間を消費します。技術が向上しても、サーバレス周りでは成熟したエコシステムが欠けており、時間がかかる要因となっています。知識や、問題解決のためのナレッジを貯めることが必要です。

A Cloud Guruでのサーバレス

A Cloud Guruが作られてから1年以上が経ちました。エコシステムは非常に早く変化し続け、ちょうど今がこれまでの旅を振り返るにいいタイミングとなっています。

まだまだサーバレスを続ける？

YES! サーバーレスによって Sam Kroonenburg は A Cloud Guruのファーストバージョンを特急で開発することができました。サーバーレスに関するエコシステム（ツール、ドキュメント、コミュニティ）が不足していたため、開発は困難でしたが。

サーバーレスについてのエコシステムは、去年1年でもっとも進化があったと思います。フレームワーク、コミュニテイ、そしてカンファレンスがサーバーレスに貢献しています。私たちはこれからも知識を共有することで、コミュニティに貢献していきたいと思います。

What’s Next?

これが本シリーズ最後の投稿です（1,2）。記事を楽しんでいただき、実際のプロジェクトにサーバーレスを導入して頂ければ幸いです。

サーバーレスを使って、どういったことをしているか聞かせてください。この記事にレスをするか、@acloudguru 宛にツイートをお願いします。サーバーレスへについてもっとお話を聞きたい方は、このブログをフォローしてください。

もっとサーバレスについての記事を読みたい方は、私の Medium か Twitter をフォローしてください。

私自身と A Cloud Guru のチームではサーバレスのトレーニングシステムをつくっています。AWSの資格や、もっと AWS Lamdba を学びたい方は、サインアップして勉強を始めましょう。

↑ここまで翻訳↑

いかがでしょうか。

サーバーレスでは開発、運用のコストを削減することができるため、今後もホットなトピックとなるでしょう。マイナス面として、開発者はクラウドに大きくアウトソースを行うため依存する形となります。

本記事の「クラウドがサービス終了」にあるリンク先の Parse.com は MBaaS で有名でしたが、2016年1月にサービスの終了をアナウンスしました。実際にサービス提供が終了するのは 2017年1月ですので、1年猶予があるのが幸いです。仮にシステムがクラウドに強く依存している場合、改修のコストは小さいものではないはずです。

AWSでは充実したサポート体制、実績、イノベーションへの挑戦があるため、他のクラウドサービスを使用するよりも安心感があります。AWS re:Invent 2016 でも、AWSがサーバーレスに力を入れている様子がヒシヒシと伝わりました。

余談ですが、今回 re:Invent 2016で John さんと会うことができました。私の体調が悪く、また次のセッションまで時間がなかったためあまりお話ができませんでしたが、ジェントルマンでナイスガイなお方でした。

A Cloud Guru の他のメンバーの方もサーバーレスに力を入れており、コミュニティの第一線を走っているのではないかと思います。これからも全世界のサーバーレスの情報を追いかけていきたいと思います。

Dear, John-san
Thank you for your kindness!