Netlifyは最強の静的ウェブサイトホスティングサービスかもしれない

セクションナイン吉田真吾@yoshidashingo)です。

ドキュメントページやブログ、企業サイトまで、静的サイトジェネレーター(Static Site Generator)でコンテンツ生成し、GitHub PagesやS3から配信をするのが一般的になりました。 逐次サーバー側で動的にリソースを生成する負担がないので、アクセス数に比例したスケール管理がしやすく、配信事業者はコンテンツサイズやトラフィック量に応じて単純な課金モデルが提供できるというのが大きい特徴でしょう。

私も、ServerlessConf Tokyoや自社のサイトでHugoを使って生成したコンテンツをAmazon S3から配信しており、Webサーバーを管理する手間がかからずとても楽に使っています。

静的サイトジェネレーターとは

下記のサイトには Jekyll, Hexo, Hugo, Octopress, Middleman など437もの静的サイトジェネレーターが羅列されています。

staticsitegenerators.net

Webサイトの構成定義ファイルやデザインテンプレートに加えて、コンテンツになるマークダウンファイルなどを準備し、コンテンツ生成コマンドを実行することで、公開用ディレクトリにHTMLやXMLやJS、画像ファイルなどのコンテンツを生成してくれます。

静的サイトジェネレータのメリット

  • CGI処理のような動的な処理が不要なので、ページごとの配信コストがアクセス数、同時アクセス数、ストレージ、トラフィックなど単純な指標で管理できる。
  • 配信の仕組みがシンプルなので障害に強いプラットフォームが多い

静的サイトジェネレーターを使ったサイト開発のワークフロー

基本的には以下のようなフローになると思います。

  • 静的サイトジェネレーターを開発環境にインストールする
  • 配信元の環境をセットアップする
  • テンプレートをダウンロードしてカスタマイズする
  • コンテンツをマークダウンで記述したり画像などを格納して文章内からリンクする
  • コンテンツを生成する
  • 配信元にアップロードする

静的サイトの配信方法いろいろ

コンテンツを日々修正したり追加するときに重要なのは上記ワークフローをどれだけ簡単に実現できるかという点になってきます。

GitHub Pages

  • master ブランチか gh-pages ブランチか master ブランチの /docs ディレクトリを指定して自動的にコンテンツの公開が可能です。
  • CNAMEを設定することで独自ドメインでの運用も可能です。
  • ワークフロー的には手元の静的サイトジェネレーターでコンテンツ生成したらGitHubにpushするだけであることと、公開元のブランチに対するプルリク→レビュー→マージ→公開といったコラボレーションがしやすい

pages.github.com

Amazon S3

  • S3バケットのWebサイトホスティング機能を有効にし、バケットポリシーをパブリック・アクセス可能にすることで格納されているファイルを公開可能です。
  • Route 53と合わせて使うことで独自ドメインにもできるし、CloudFrontと組み合せることでグローバルなアクセスでも近いロケーションからの配信ができたり、ACMとの組合せでHTTPSのSSL証明書を無料で利用できたりします。

docs.aws.amazon.com

静的サイトホスティング専用サービス

数年前からBitBalloonのような zipファイル でサイトを丸ごとアーカイブして投げ込むことでサイトとして公開してくれるサービスがありました。

www.bitballoon.com

これはこれで少人数でさほど更新のかからないサイトであれば便利なのですが、サイトの構造定義やコンテンツをGitHubなどのリポジトリで管理しており頻繁に内容の修正や追加を行いたい場合には、リポジトリと統合されて一貫性のあるワークフローでサイトの開発を行いたいという要望が発生するのはごく自然なことです。そこでそういったワークフローをカバーしているのが Netlify です。

ServerlessConf NYCで「10X Product Development」というタイトルでトークしたJoe Emisonが、フロントエンド開発にフォーカスするために利用していたサービスの一つ「Netlify」として紹介されていました。

www.slideshare.net

f:id:yoshidashingo:20160822114023p:plain

トップページのキャッチコピーがコンセプトを表しています。

Write frontend code. Push it. We handle the rest.

「フロントエンドのコードを書いてPushしたら、あとはお任せください」

Netlifyの特徴

昨年創業して数日前に $2.1M (約2億円) の資金調達をしたスタートアップだけあり、上記で書いたような開発ワークフローの要望などに対応しています。

techcrunch.com

(1) Gitリポジトリと連携したホスティング設定

設定はコンソールからGitHubなどのGitリポジトリを指定してアクセス許可をするだけです。 プライベートリポジトリの場合はNetlify用の公開鍵が追加されます。

(2) 独自ドメイン設定

DNS(Route 53)の設定を以下のような感じで行うとZone ApexのAレコードとwwwサブドメインのCNAMEを設定することで独自ドメインの設定ができます。

f:id:yoshidashingo:20160822184849p:plain

(3) Gitリポジトリにpushするだけの継続的デプロイ

Netlifyではリポジトリからwebhookを受け取ると自動でリポジトリをpullして「ビルド」と「デプロイ」を行います。これにより、ローカル環境でビルドを行う必要がないので、コンテンツが大量にあるサイトや開発者の手元の環境のツールのバージョンに依存しない(たとえば寄稿者はマークダウンを記載してpushするだけで投稿できるようにしたい場合など)環境ができます。

従来このワークフローに対応するためには、GitHubのリポジトリのwebhookを受け取ったCIサービスの中で、「SSGのコマンドをインストール」して「ビルド実行」して「公開ディレクトリを配布する」というプロセスを作る必要がありました。

Netlifyでは以下のような設定をすることで、リポジトリにpushすると「特定のコマンドを実行(たとえばhugo)」して「デプロイ」するように指定ができます

  • たとえば sec9.co のディレクトリ構造がこうなっているとする
~/github/sec9.co $ tree -L 2
.
└── hugo
    ├── archetypes
    ├── config.toml
    ├── content
    ├── data
    ├── layouts
    ├── public
    └── themes
  • Netlifyコンソールでドメイン/リポジトリ/ブランチ/ビルドコマンド/公開フォルダを設定する(hugoディレクトリに移動してhugoコマンドを実行して、hugo/publicを公開するという設定)

f:id:yoshidashingo:20160822184300p:plain

  • リポジトリにpushするだけで自動的にサイトをNetlify側でビルドして公開してくれる。

f:id:yoshidashingo:20160822185255p:plain

  • ちゃんと公開されている

f:id:yoshidashingo:20160822184807p:plain

※CDNの機能をフル活用するためにはZone Apexでの運用は非推奨になっています。

(4) HTTPSサポート

組込みでLet's EncryptによるSSL証明書の発行・更新をサポートしているので、上記の例でも使いましたが、コンソールから1クリックで証明書の発行やインストールしてくれます。

(5) HTTP/2サポート

GitHub PagesやS3では対応していないHTTP/2による配信に対応しています。

料金プラン

ここまでは無料で使える範囲の機能でしたが、さらに高機能なプランがあります。

f:id:yoshidashingo:20160822192606p:plain

以下は有料プランで使える機能です。

(6) Geo-IP

公開されたサイトは基本的にCDNに載せて配信されるようですが、今回の確認ではフリープランであり、レスポンスがちょっと遅いなと感じました。調べるとアメリカから配信されているようなので、レスポンスタイムをもっと短くしたいということがあればプランのアップグレードを検討すると良いと思います。

$ curl -kL https://sec9.co -o /dev/null -w}\t%{time_total}" 2> /dev/null
200 3.375

$ nslookup sec9.co
Server:     172.20.10.1
Address:    172.20.10.1#53

Non-authoritative answer:
Name:   sec9.co
Address: 198.61.251.14

f:id:yoshidashingo:20160822191930p:plain

http://www.iputilities.net より

(7) SPA用のプリレンダリング

SEO対策などのために組込みのプリレンダリングエンジンを使い(Prerender.ioなども利用可能)JSで生成されるコンテンツをキャッシュさせることができます。

(8) SLA契約

最上位のGLOBALプランを利用すると、アップタイムのSLAが締結できるようです。

(9)フォーム設置

こちらも有料プランですが、静的サイトで懸案になりがちなフォームの設置を行うことができるようです。

まとめ

ということで、まだ新しいサービスにも関わらず、かなり高機能に仕上がっている印象のNetlifyでした。

先週のAWS関連ブログ〜8/21(日) - AWS Summit NYC, 国勢調査サイトをサーバーレスでコストダウンするハッカソンなど

どうも、セクションナイン吉田真吾@yoshidashingo)です。

ここ2週間は日本はお盆ウィークということでしたが、私のほうはServerlessConfのトークセッションやチケット販売やプレカンファレンスの準備やらいろいろやっていました。なかなか思っていたより手間がかかるものですね。それではこの2週間のAWSのアップデートを振り返ってみましょう。

AWS公式

先週、今週は結構機能リリースが多かったですね。

1. サーバーレスでChatbotコンテスト開催

  • Slack / API Gateway / Lambda を使ったChatbotコンテストが開催される
  • 顧客に対する価値、アイデアの質、実装内容の3点を評価される→ルール
  • ビデオや説明文、ソースコードのリポジトリ、使用手順などを2016/9/29までに英語で提出する

リンク:サーバーレスでChatbot コンテスト開催 | Amazon Web Services ブログ

2. Amazon Elastic Block Store(EBS)アップデート-スナップショットストレージの値下げとPIOPSボリュームのIOPS/GB比率の改善

  • PIOPS EBSのIOPS/GB比率が30IOPS/GB→50IOPS/GBに引き上げられた
  • EBSスナップショットの費用が47%値下げされた(Storage Gatewayのゲートウェイキャッシュ型ボリュームのスナップショットも同様)

リンク:Amazon Elastic Block Store(EBS)アップデート-スナップショットストレージの値下げとPIOPSボリュームのIOPS/GB比率の改善 | Amazon Web Services ブログ

3. 【新発表】AWS アプリケーションロードバランサー

  • コンテントベースルーティングできるL7LB、ALBが利用可能に
  • リクエストされたURLパスに応じてルーティング先のサーバー群(ターゲットグループ)を指定可能に

リンク:【新発表】AWS アプリケーションロードバランサー | Amazon Web Services ブログ

4. 強力なAWSプラットフォームの特徴、コンテナ向けに

  • ECSのタスク定義で「動的ポート(EC2ホスト側のポートに自動で未使用のポートを割り当てる)」:ALBを先に作っておき、ECSでタスク定義を作成する際にHost portを0と指定する
  • (リリース済み)「ECSタスクにIAMロール指定(5月)」「サービスAuto Scaling(7月)」がいずれも7月から「東京リージョンで利用可能」になっている。
  • Docker 0.11で入ったホストネットワーク機能としてBridge/Host/Noneが指定可能になっている。
  • ECRが東京リージョンでも利用可能になった。

リンク:強力なAWSプラットフォームの特徴、コンテナ向けに | Amazon Web Services ブログ リンク:Amazon EC2 Container Service Now Supports Networking Modes and Memory Reservation リンク:Amazon EC2 Container Registry Region Expansion

5. Amazon API Gatewayのための利用プラン

  • アクセス元のユーザーごとにAPIキーを払い出し、APIのステージを選択して、プラン名/スロットリング(RPSやバースト可能なリクエスト数)/クォータ(期間内の上限リクエスト数)を指定可能になった。
  • ステージごとにプランを指定し、プランに対応するAPIキーを指定することで、利用制限はユーザーごとの優先度などが設定できる。
  • 利用実績はダウンロード可能なので、クォータでアクセスを止めたくないリクエスト数で後払いのような課金にも対応可能。

リンク:Amazon API Gatewayのための利用プラン | Amazon Web Services ブログ

6. AWS Snowball アップデート – ジョブ管理API & S3 アダプタ

  • APIコールでSnowballを配達してもらえるようになった。->ジョブ管理APIのCreateJob/ListJobs/DescribeJob
  • Snowballへのデータの出し入れは「S3 アダプタ」をインストールすると、aws s3サブコマンドでs3を扱うようにSnowballを指定して利用可能になる。

リンク:AWS Snowball アップデート – ジョブ管理API & S3 アダプタ | Amazon Web Services ブログ

7. AWS Key Management ServiceでのBring Your Own Keys機能

  • マネージメントコンソール/AWS CLI/KMS APIを使って、外部HSMから鍵をインポートしてアプリなどから利用可能になった。
  • インポートする際に鍵のコントロールが可能なIAMユーザーの指定が必要
  • 鍵は有効期限を設定でき、CloudWatchアラームを指定すれば、有効期限が近づいた場合に再度インポート(Lambdaとかで実装するとよさげ)することで、外部HSM側でのコントロールを行うことが可能(若干タイムラグが起こるだろうが外部HSM側でのインバリデート処理と連携など)

リンク:新発表 – AWS Key Management ServiceでのBring Your Own Keys機能 | Amazon Web Services ブログ

8. 東京リージョンのOpsWorksのリソースへのアクセスを東京リージョンのエンドポイントで実行可能に

  • 従来、東京リージョンのOpsWorksのリソースへのアクセスをUS-Eastのエンドポイントを指定して実施する必要があったが、これが東京リージョンのエンドポイントができたことでそちらで実行可能に。APIアクセスが少し速くなったりUS-Eastの障害に左右されなくなったという話。

リンク:AWS OpsWorksが9つのリージョンエンドポイントとアジアパシフィック(ソウル)リージョンをサポート | Amazon Web Services ブログ

9. Amazon Kinesis Analytics - SQL を使用してリアルタイムにストリーミングデータを処理

  • 昨年のre:Inventで発表されたAmazon Kinesis AnalyticsがUS-East/US-West(Oregon)/EU(アイルランド)で利用可能に(Firehoseと提供範囲は同じ)。東京リージョンはまだ。
  • Kinesis StreamやKinesis Firehoseのストリームをソースとして指定し、クエリ範囲となるウィンドウのタイプを選択し、SQLエディタで書いたクエリを実行(ウィンドウ範囲に対してフィルタになる)して、出力先のストリームを指定して連携することができる。
  • また、フィルタ結果はS3/Redshift/Elasticsearch Service/Kinesis Streamの指定先で最大4箇所にルーティング可能とのこと。(手元で試している限り、直接Destinationに指定可能なのは「Kinesis Stream」「Kinesis Firehose」のみに見えるので、Firehose経由でその他のリソースに連携するということに思える)

f:id:yoshidashingo:20160821191904p:plain

リンク:Amazon Kinesis Analytics - SQL を使用してリアルタイムにストリーミングデータを処理 | Amazon Web Services ブログ

www.slideshare.net

10. Transit VPC

  • 複数のVPCやオンプレミス環境やサードパーティサービスからの接続を、各ネットワーク間ごとに管理していくと、複雑なネットワーク構成になってしまい管理が大変になることがある。「Transit VPC」方式は中央にすべてのネットワーク同士の接続を中継するVPC(CISCOの仮想ルーターCisco Cloud Services RouterをMarketplaceから使う)を配置することで、複数のネットワークの接続を一元管理できる方式
  • サンプルとなるCloudFormationのテンプレートを使って作成することができる。

リンク:AWS ソリューション – Transit VPC | Amazon Web Services ブログ

11. Amazon S3 が IPv6 をサポート

  • 従来のエンドポイントとは違うデュアルスタックエンドポイントを解決するとIPv6アドレスが返ってくるようになった。
    • http://BUCKET.s3.dualstack.REGION.amazonaws.com または http://s3.dualstack.REGION.amazonaws.com/BUCKET という形式
  • IPv6でもS3のすべての機能が利用可能。

リンク:サービス開始 – Amazon S3 が IPv6 をサポート | Amazon Web Services ブログ

12. WorkSpacesが時間課金可能/自動停止できるようになり、ルートボリュームが大きくなった

  • WorkSpacesはAlwaysOnか時間課金か選択できるようになり、時間課金の場合、スタートから何時間後に自動停止するかも指定可能になった。
  • 一定時間経過して自動停止した場合、再度接続するときに「Resuming...」になり、1〜2分で接続可能になる。

f:id:yoshidashingo:20160821194053p:plain

(まぁ、何回かエラーになったりもするが...)

  • 既存のWorkSpacesも「Modify Running Mode Properties」で変更可能になった。
  • 各バンドルのルートボリュームが大きくなった。(たとえばPerformance Modelは100GB)

ということで、仕事で使っている場合、トータルでかなり安くなるので、これはもう1人1WorkSpace利用してローカル環境を持ち上げてもよいのではないかと思います。

f:id:yoshidashingo:20160821193009p:plain

リンク:Amazon WorkSpaces Update – Hourly Usage and Expanded Root Volume | AWS News Blog

13. AWS利用料をRedshiftとQuickSightに自動連携可能に

  • 毎時/毎日のAWS利用料をRedshiftとQuickSightに直接連携可能になり、簡易的なダッシュボードなどが非常に簡単につくれるようになった
  • Billing and Costマネジメントコンソールのreport欄で設定が可能

f:id:yoshidashingo:20160821195718p:plain

リンク:AWS Cost and Usage Report Data is Now Easy to Upload Directly into Amazon Redshift and Amazon QuickSight

14. Netflix OSSのデプロイメントツール「Spinnaker」をAWS上に構築する方法

  • リファレンスが公開された

リンク:Netflix OSS Spinnaker on the AWS Cloud: Quick Start Reference Deployment

www.spinnaker.io

https://s3.amazonaws.com/quickstart-reference/spinnaker/latest/doc/spinnaker-on-the-aws-cloud.pdf

15. EC2 Dedicated Hosts ReservationsがマネジメントコンソールやCLIから指定して購入可能に

  • ホストサーバー単位のライセンスを利用するためのDedicated Hostsのリザーブド購入をマネジメントコンソールやCLIから可能に。
  • 操作的には「オンデマンドでDedicated Hostsを用意して」「起動中のDedicated Hostsを指定してリザーブド購入」

リンク:Amazon EC2 Dedicated Hosts Reservations are available in the AWS Management Console and AWS CLI

AWS関連

16. PowerShellがOSSになり、LinuxやMacでも利用可能に

  • GitHubでソースコードが公開されるとともに、(Windowsはもとより)LinuxやMac用のバイナリの配布が開始された。

https://msdn.microsoft.com/en-us/powershell

  • これに合わせてAWS用のモジュールである「AWS Tools for PowerShell Core Edition(AWSPowerShell.NetCore)」も同様にマルチプラットフォームをカバーすることになり、数日以内にPowerShell Galleryに公開予定と発表

※8/21現在はまだなさそうだ。

https://www.powershellgallery.com/items?q=AWS+Tools+for+PowerShell+Core+Edition&x=0&y=0

https://blogs.aws.amazon.com/net/post/TxTUNCCDVSG05F/Introducing-AWS-Tools-for-PowerShell-Core-Edition

17. オーストラリアの大学1年生2人が政府の国勢調査サイトのハッカソンにおいてサーバーレスアーキテクチャで置き換えて優勝

Make Census Great Again

eftm.com.au

  • ABS Censusというオーストラリア政府の国勢調査のサイトが、ここ5年ほどアンケートに答えるためにたくさんの人がログインするたびに24時間以上ダウンしている。
  • これを置き換えるコンセプトで開催された54時間のハッカソンで、大学1年生2人がでサーバーレスアーキテクチャに置き換えるデザインで構築し、負荷テスト(100万PV/時間)をクリアし優勝した。

www.mailonsunday.co.uk

※当の国勢調査サイトはずっとダウンしてますね

http://census.abs.gov.au

その他

18. Amazonのソフトウェアエンジニア面接

  • 電話面接や丸一日かけて何人とも面接をしたこと、またはいろいろとそれに合わせて準備したことなどが書かれている。
  • 外資系のIT企業に面接に行くときに参考になりそうだ。

postd.cc

19. Otto、廃止へ

  • 昨年のHashiConfで発表されたOtto、Vagrantの後継+開発プロセス全体の統合を図っていたが、コアの抽象度の保持と独自機能が当初目指していたゴールにまで到達できそうにないということで早々と廃止を決定し再出発となった。
  • 積極的な開発は今後行われないが、リポジトリは引き続き公開される。
  • 意思決定の速さについては評価する声が多い。

https://www.hashicorp.com/blog/decommissioning-otto.html

ServerlessConf Tokyoではスピーカーとスポンサーを募集しています

どうも、セクションナイン吉田真吾@yoshidashingo)です。

今年5月にNY、ブルックリンで開催されたServerlessConf NYCから約2ヶ月。2箇所目として「東京」が9/30&10/1、3箇所目として「ロンドン」が10/26-28に開催されることが発表され、サーバーレスの勢いはますます増しています。

tokyo.serverlessconf.io

東京開催についてセクションナインが担当することになりましたが、NYCで話したスピーカーやスポンサーも決まっており、もう少ししたら詳細の発表やチケット販売を開始できるようになると思います。お待たせしてすいません。

Serverlessとは?

サーバーレスはクラウドコンピューティングの「使った分だけ」という原則についてもっとも近い考え方です。

特にここにきて注目されている要因は2つあり、(1)クラウドプラットフォーム側がリクエスト単位に実行環境を準備できるようになった(後述:関連するパラダイムシフト)という話と、(2)ユーザーが、クラウドの特徴を活用する前提でアプリと統合されたアーキテクチャをはじめから考えるようになってきたことでServerlessifyしやすくなってきたという認識です。

martinfowlerブログ(執筆者はMike Roberts氏)に記載されているように活用形態として代表的なのが「UIドリブンアプリケーションのバックエンド」と「メッセージドリブンアプリケーション」というのが現在の共通認識ですが、今後はプラットフォーム側の提供するソリューションの拡大や、ユーザー側の使い方によってもう少し対象範囲が広くなっていくかもなと思っています。

martinfowler.com

あと、元A Cloud GuruのAntのスライドも、マネージドなSaaSからサーバーレスなサービスまで広く整理するにおいて非常に分かりやすいです。

http://www.slideshare.net/acloudguru/ant-stanley-being-serverlesswww.slideshare.net

関連するパラダイムシフト

プラットフォーム側の実装がリクエスト単位に実行環境を準備できるようになった背景として、ここ20年くらいのパラダイムシフトを挙げるとすると以下のようなものがあると思います。

  • ライセンス形態によりポータビリティの束縛があるプロプライエタリソフト→依存性を解決するパッケージシステムを通じてどこでも実行環境が構築可能なOSSの利用が増えたこと
  • Infrastructure as Codeによるアプリ/インフラともにソフトウェアのベストプラクティスを適用して管理するのが一般的になってきたこと
  • Dockerイメージなどのコンテナイメージを用いて即座に実行環境を準備可能とするリソース調達モデルの変化(※俗にまるでCGIのような実行環境の調達方法と言われる)※プラットフォーム側としてはこれが直近で非常に大きい
  • 機能ごとにマイクロサービス化するためにREST APIで機能を束ねてインタフェースを担わせるアーキテクチャの普及や期待値の高まりにより、インタフェース部分の汎用化・標準化が進んだ→インタフェースさえ変わらなければ自分の環境だろうがどこかのクラウドサービス上だろうが機能ごとにポータブルに配置可能となった ※利用者側の変化としては直近でこれが大きい
  • などなど...

これらがすべて合流した結果がFaaSやAPIを活用したサーバーレスアーキテクチャに結びついたものと個人的にとらえています。

活用シーンの例

代表的なものとして以下のような物が考えられます。自分の組織で管理するもよし、SaaSも活用するもよしです。

  • APIサービスとして単機能をAPI Gateway+Lambdaで実装する。認証/認可を行い属性やステータスを管理するDBサービスなど。
  • シングルページアプリケーションのバックエンドをAPI Gateway+Lambdaで機能実装する。あるいは静的ページであれば(HugoやStaticPress)S3に配置し必要に応じてCloudFrontやACMを設定して配信する。
  • iOSアプリやAndroidアプリのバックエンドをAPI Gateway+Lambdaで機能実装する。
  • ログが格納されたらイベントドリブンで解析して、結果をどこかに永続化して、またイベントを発火して終わる。
  • などなど...

Serverlessはベンダーロックインか?

理想から言うとむしろアプリのポータビリティが上がるので逆ですね。コードを持ち込むだけだったり(FaaS利用)、インタフェースが標準化されたり(REST APIベース)、あらゆるプラットフォームにデプロイできたりその定義を再利用できたり(フレームワーク)という方向に向かっているので、将来的な心配はしなくていいのではないかと思います。

そもそもベンダーロックインが「悪」だとされるのは「ライセンスを資産として買い切りさせられるために減価償却の5年間は乗り換えられない」「仕様がブラックボックスなのに、バグっぽい挙動を問い合わせるためには細かい情報を自分で収集して提供しないといけない(ベンダーとユーザーの情報の非対称性)」などを指して言われることが多いと思うので、ここらへんがクリアになるようにプラットフォームを選定しておけば問題ないと思います。

FaaSやAPI以外へのサーバーレスの拡大の可能性

現状のFaaSは単一コアでの一定時間/メモリ量でのコード実行に限られており、Hadoopのような並列分散処理のようなことを簡単には実現できない(S3に上げたデータをLambdaで切り分けてDynamoDBに入れてから各データを並列実行とか実装するだけでだいぶしんどいしディスクやネットワークのIOを最適化できない)です。プラットフォームの中身を気にしなくてもそういった処理が現実的な処理時間やコストで実現可能になる可能性はあると思います。

エラー処理の作りやすさや、複雑なワークフローのジョブネットを簡単に構築できたりというあたりも今後より重要視されてくるかもしれません。

運用のResponsibility、NoOps

通常Opsはカスタマーに提供するサービスレベルを設計し、十分担保できる技術を採用したりサービスを採用したりしますが、いわゆる世に出回っている便利なSaaSにはこのサービスレベル設計において必要な情報(SLA、SLO、内部仕様の公開、トラブルシュートのためのドキュメント、などなど)が足りてない傾向にあることはたしかです。お金を払ってサービスを利用しているからといってそれを用いてカスタマーに提供しているサービスの最終責任者が自分であることには変わりません。そのSaaSがSPoFにならないか、トラブった場合にどう影響範囲を切り離したり別のサービスに切り替えたり、あるいは縮退運転するか、などは自分で考える必要があります。

そういったもろもろをPodcastで語ってみました

cloudinfra.audio

ServerlessConfはどんなイベントか

ベンダーニュートラリティ

今後のサーバーレスの広がりを考えると、特定のベンダーだけが得意な分野ではなくなっていくものと推定されます。なぜなら、UIドリブンアプリケーションやイベントドリブンアプリケーションという、Webシステムの文脈だけでなく、たとえば大規模分散コンピューティング環境や、IoT、音声認識やテキスト分析、深層学習といった分野でもServerlessでアプリ利用する瞬間だけ実行環境が用意されるというモデルに近づくことが予想されているからです。

ということで、当初からそういった文脈をすべてオープンに受け入れて会話できる新しいコミュニティが必要だなと認識しており、いい機会だったので日本市場でのServerlessConfの実施のライセンスをしてもらったのが発端です。

やっていく気持ち

ということで、サーバーレスは「ユーザーがポータビリティの高いコードやインタフェース定義を作ることに専念し、自分の要件に合ったプラットフォームを選別して(あるいは適切なプラットフォームがなければそれは自分で作るかもしれないが)、その知見を共有しあいながら議論を高めていける」極めてフェアなプラットフォームの利用形態ではないかと考えています。

よってこのコミュニティに現在大事なのは、どのようにしてポータビリティの高いアプリを作り、プラットフォームやツールを選別しているかといった知見を自分自身で体験して共有するということであり、自分がその議論を先導するための「やっていく気持ち」をもって取り組むことだと思います。

スピーカーとスポンサーを募集しています

ということでServerlessConf Tokyoではスピーカーとスポンサーを募集しています。どちらもサイトから必要事項を添えてメールでご応募ください。

tokyo.serverlessconf.io

スピーカー

上記で述べたようにさまざまな文脈が入り混じって混沌としているのが現在のサーバーレスです。自分はこの分野においてサーバーレスとの関係をこう考えている、などの意見を積極的に発表していくことが、日本におけるサーバーレスの文脈の深化につながっていきます。

以下のような文脈を想定しており、すでにかなりの応募をいただいています。第1弾としては8/8(月)くらいまでには選定したいと思っています。

  • サーバーレスな環境を提供するプラットフォームの話
  • サーバーレスを便利に利用するフレームワークの話
  • サーバーレスを使った開発の話
  • サーバーレスを使ったOpsの話

スポンサー

ServerlessConfはサーバーレスの活用を推進するたくさんのエンジニアによって構成され、参加者の幅はフロントでJSをコーディングしている人からインフラを作っているエンジニアまで多岐に広がっています。このリージョナルイベントをスポンサーシップとして応援してください。また、今後Meetup系の小規模イベントを合同企画させていただくことも可能になると思います。興味があればぜひお問合せを。