The Doppler Quarterly (日本語) 春 2017 | Page 42

1. セキュリティ
サーバーベースの展開時に予測されるベストプラクティスが、サーバーレスの機能にも同様に
当てはまります。次の観念を検討します。
• アイデンティティ管理が第一戦の防御であることに変わりはありません。
• 特に興味深い新たなパターンは、関数のラッパーです。このラッパーは、トリガーイベント
の入力をセキュリティアナライザー ( つまり Alert Logic) に渡し、コンテンツ OK の結果
が返る場合にのみ主な関数に進みます。
• エンドポイントを保護するフロントエンドとして API Gateway を使用します。
2. 監視
監視は、サーバーレスの問題の中でも扱いにくい部分とされてきましたが、たとえば、 AWS
は、 AWS Lambda の機能の監視に Amazon CloudWatch を事実上のメカニズムとして使
用しています。これにより、その他の AWS の標準監視機能にシームレスに追加できます。
3. レイテンシ
サーバーレスコンピューティングに関して、レイテンシはもう1 つの考慮すべき問題です。JVM
の起動によって呼び出される頻度が少なくなると、 Java の起動が遅くなる場合があることに
注意します。しかし、これは JavaScript または Python には当てはまりません。
4. 言語のバージョン
サーバーレスの機能に選択した言語によっては、サービスでサポートされるバージョンに関連
して問題が発生することがあります。たとえば、 AWS Lambdaでは、 Node.js v4.3.2 がサポー
トされていますが、推奨されるバージョンは、 v6.10.0 です。同時に、 AWS Beanstalk では、
v6.9.1 がサポートされているため、利用するクラウドプロバイダー内のサービス全体で一貫性
を維持することも課題になります。
5. 制限事項
さまざまなクラウドプロバイダーが、最長実行時間、リクエスト/ レスポンスペイロードの最
大サイズ、最大の一時ディスク領域、同時実行数などの制約を含む、さまざまな制限事項を
サーバーレスの機能に組み込んでいます。これらの制限はプロバイダーの要求に応じて増え
る場合もあることに注意してください。
実例
Bustle.com は、毎月 5,000 万人の読者がアクセスする、ニュース、エンターテインメント、ラ
イフスタイル、ファッション情報の Web サイトです。Bustle は、拡張性の問題とインフラスト
ラクチャ管理のオーバーヘッドの解消に取り組んでいました。サーバーレスアーキテクチャー
に移行し、運用チームを半数に縮小して、全体で 80% のコスト節減を実現しました。
Moonmail は、メールマーケティングプラットフォームを eCommerce コミュニティに提供し
ています。既存のEC2とRuby on Rails 環境を完全なサーバーレスソリューションにリプレー
スし、実質的に無限の拡張性を達成しました。Serverless Framework を活用してたった 2
週間で実装を完了しています。このような結果により、迅速なイノベーションという究極の目
標が実証されます。
40 | THE DOPPLER | 2017 年春号