[ServerlessDays Tokyo 2019] ISPがサーバーレスに手を出した
遅くなりましたが、10/22(火)に開催されたServerless Days Tokyo 2019のセッションレポートです。
登壇者
NTTコミュニケーションズ
伊藤良哉
松田丈司
スライド
https://speakerdeck.com/georgeorge/isp-challenges-serverless
レポート
- ISPとは
- 公衆通信回線を経由して、インターネット接続を提供する事業者
- OCN V6アルファ
- IPoE対応ルータを使用して、IPv6接続とIPoEインターネット接続が可能になるオプションサービス
- この開発でサーバーレスアーキテクチャを採用した
- ISPでサーバーレスをどこで使っているのか
- OCNが採用しているIPv4 over IPv6方式はMAP-E
- MAP-EではIPv4/IPv6変換ルールを通信開始前に取得する必要がある
- このMAPルール配信機能をサーバーレスアーキテクチャで作った
- サーバーレス導入までの道のり
- これまでの選択肢では、物理サーバが第一選択肢、ついでNTTコミュニケーションズでは自社IaaSを持っているため、仮想化する場合は自社IaaS。ついで他社IaaSサービスの順で選択肢があったが他社IaaSは自社サービスと競合するため使いづらかった。サーバーレス以外の選択肢だと、納期が3ヶ月しかないため間に合わない。他社クラウド会社が、初めての取引先相手だったため与信審査が必要だった。
- 社内クラウドを利用しない理由
- IPv6対応されていなかった。。。
- IPv6の課題
- Azure Function、API GatewayともにIPv6対応がされていなかっため、CDNを前段に配置しIPv6対応を実現
- なぜ、サーバーレスでチャレンジできたか
- リリース延期の危機
- すぐに用意できる環境が必要
- コードを書くだけでOK
- テクニカルな実践・問題
- AWS、Azureのマルチクラウド環境でやっていたが、構成変更しなければいけない問題がでてきた
- Azure CDNのSSL証明書のCNがカスタムドメインにできない
- マルチクラウド環境なためシンプルにする必要がある
- AWS単独構成のマルチリージョン環境に変更。DynamoDBのリージョン間同期は、DynamoDB Stream→Lambda→SQSで実現
- そんななか、DynamoDB グローバルテーブルが発表されこれでさらに簡単に実現できるとなり、構成をグローバルテーブルレプリケーションに変更
- サーバーレスとの安全な付き合い方
- Webコンソールから、動かすのは簡単だが管理が大変。以下のような、考慮が必要になる
- Infrastructure as Code
- Serverless Flamework
- CI/CD
- GitLab CI
- ローカルテスト
- Serverless Flameworkのローカルテストプラグインを採用
- Lambdaハンドラにeventを直接与えて、正常系・異常系を網羅
- なるべくローカルでテストを済ませる
- 負荷試験
- Gatling(https://gatling.io)を採用
- Servelrss Flameworkでの構成変更
- Serverless Flameworkで、構成変更を行う場合
Immutable Infra
をベースに行った。
- 新構成を
sls deploy
- データをダウンタイムなしで旧構成から新構成に移行(Data Pipelineなどを使って)
- originを新構成に切り替え
- 旧構成を
sls remove
- 運用・デバッグ
- CloudWatchでダッシュボードを作成している
まとめ
ISPがサーバーレスを採用した事例でした。テストやCI/CD、負荷試験、構成変更のデプロイ方法などにも言及していとても参考になりました。また、サーバーレスを適用できる範囲に限定して採用している点も参考になる方が多いんではないかと思いました。