AWSのLambdaをはじめとして、各種クラウドサービスでサーバレスのサービスを提供するようになってきて、サーバレスによるシステム構築の注目度合いも高まってきています。一方で、サーバレスの事例が増えるに従って、サーバレスが効果を発揮する用途が何か、サーバレスとすることによるデメリットなども指摘されるようになってきて、サーバレスが本格的に浸透していく段階を迎えていることも感じます。サーバレスはデバッグが難しい、サーバレスアーキテクチャの開発を行うための各種ツール、エコシステムがまだ十分にできていない等の、サーバレスに関するオンラインメディアの記事からピックアップして紹介します。
※下記サイトからの転載。ビッグデータ・AIなどに関するトピックを毎週取り上げています。
TechCrowd: https://www.techcrowd.jp/related/
次のビッグウェーブはサーバーレスだ――新たなスタートアップ・エコシステム構築のチャンス
TechCrunchのトピックス記事です。
サーバーレス・アーキテクチャというコンセプト自体は以前からあったが、いよいよ大きくそのメリットが発揮される状況となってきました。サーバーレスに関するスタートアップ・エコシステムが構築される可能性が出てきており、サーバーレス・コンピューティングを助け、セキュリティーを確保するために必要なツール、ライブラリ、API、ダッシュボード、その他あらゆるユーティリティーの作成が大きなビジネスチャンスとなるだろうというトレンド観測の記事です。
サーバーレスに関する現状の調査データも引用してくれています。年間にサーバーレスでアプリケーションを開発したことがあるかという質問に3分の2が「ない」と回答しておりまだサーバーレスでのアプリケーション開発は十分に浸透していないのがわかります。また、サーバーレス・モデルを利用しているユーザーの中ではAWSが他を大きく引きはなしたトップとのこと。回答者の58%がAWS Lambdaをツールとして使っていると回答。Google Cloud Functionsが23%、Microsoft Azure Functionsが10%で続いている。
サーバーレスを採用することに抵抗がある層はその理由としてツールの欠如を挙げている。Digital Oceanのレポートでは「サーバーレス・モデルでデベロッパーが直面するもっとも大きな困難の一つはモニタリングとデバッギングだ」と述べている。
デベロッパーがサーバーレス開発にアクセスしやすくなるよう、セキュリティを含むさまざまな側面を改善しなければならない面があるが、その中でも、サーバレス開発で必要となる各種ツールの整備がまだまだ必要であり、それは逆にスタートアップにとってのチャンスであると結んでいます。
サーバーレスでNoOps実現、10万件のバッチ処理を改造
「システム導入のための意思決定支援サイト」日経XTECH ACTIVEのインフラ構築/運用分野におけるゼンアーキテクツの岡さんの投稿記事です。
システム運用の自動化を目指す「NoOps」。クラウドやサーバーレス、自動化ツールといった技術を活用してシステムに回復性を持たせ、障害からの自己修復を可能にするものですがNoOpsを実現する手法の中で、サーバーレスを取り上げています。
障害からの自己回復性をもたせNoOpsを実現するためには、システム基盤であるプラットフォームと、その上で動作するアプリケーションの双方が回復性を持つ必要があるが、この記事ではアプリケーションの回復性の実現方法と、その中でサーバーレス関数を利用することの
メリットを解説しています。
まずアプリケーションに回復性を持たせる設計のポイントは、いつでもどこでも何度実行しても同じ結果が得られる「冪等性（べきとうせい）」をアプリケーションに実装すること。またJob単位で新規インスタンスを生成、実行するサーバーレス関数を使うことがNoOpsの観点から有用とのこと。
サーバーレス関数を利用するメリットはふたつ。1つは回復性の観点から、長期間の大量Job実行によるメモリーリークなどによる失敗の可能性を抑えること。もう1つは、Jobの並列実行可能性を持たせること。
以上の設計のポイントが実現されれば、Jobの実行に失敗しても、キューが詰まったとしても自律的に回復できる素地が整っている状態となる。あとは全ての処理結果を記録し、動作中に発生し得る「失敗」をモニタリングし回復させる処理を継続的に積み上げていく。それにより手作業での運用を徐々に減らしていくことができるとのことです。
サーバレスに飛び付く前にやるべきたった1つの作業
TechTargetジャパンのクラウド分野の記事です。
「サーバレス」コンピューティングという言葉が使われる場合、コンテナ、マイクロサービスなどの抽象概念を（間違って）示している場合も多いが、本当は「Function as a Service」（FaaS）を指しています。
したがってサーバレスは、主に短時間しか行われない相互作用を対象に設計されています。そのため多くのサーバレスプロバイダーは、5分を超えて続行するスレッドを終了します。
サーバレスの恐らくもっと重要なメリットとしてあげているのは、水平方向の柔軟なスケーリングが極めて簡単になることとのべています。
そしてサーバレスに切り替える前に考慮しなければならないことが幾つかあると指摘しています。
まずサーバレスでは言語のサブセットしかサポートされない。サーバレスを有効活用しようと考えているなら、選んだFaaSプロバイダーがサポートする言語を調べることが重要になる。例えば、「AWS Lambda」がサポートするのは、Go、JavaScript（Node.js）、Java、C#、Python。またサーバレスを稼働させるには、膨大な量のテストが必要になる。その性質上、デバッグは非常に難しい。また、全ての種類の用途に適しているわけでもない。
そして最も重要なのは試算とのこと。これにはテスト、再設計、とりわけ開発者のスキルセットといった全てに関するコストが含まれる。サーバレスに飛びつく前に試算が必要だとして結んでいます。
“究極の名寄せ”を実現する、サーバーレスアーキテクチャの作り方
ログミーの講演レポートです。
2018年4月17日、レバテック株式会社が主催するエンジニア向け勉強会「ヒカ☆ラボ」にて「究極の名寄せのためのサーバーレスアーキテクチャ」という題にて、Sansan株式会社の高橋洸氏が登場。同社が手がける名寄せサービスにおけるアーキテクチャ設計について紹介してくれた講演についてレポートしている記事です。
Sansanの名寄せサービスを構築するにあたり、サーバーレスアーキテクチャで構築した経験を講演してくれていますが、サーバーレスでサービスを分割できるメリットとしてあげているのは可用性の向上、独立したデプロイが可能となること、それから個別にスケーリングが可能となるという三点をあげています。
各サービスで最適な技術選定ができるのもメリットとしてあげています。全体がほぼC#で書かれているようですが、Webのところはnode.jsで書いてあったりするとのことです。
ただ、デメリットもあって、どうしても複雑になってしまうということ、テストが大変だったり、何かバグっぽいことが起こって、このサービスでエラーがおきたときに、そのサービスのバグなのかどこか前段のサービスで作ったメッセージが悪くてエラーになっているのかみたいなさかのぼって調査することが非常に大変になってくるとのことです。