Recomendados
Recomendados
Más contenido relacionado
Más de Daisuke Nishino
Más de Daisuke Nishino (7)
Último
Último (8)
Serverlessconf Tokyo 2017 Report - Daisuke Nishino(Sompo Systems)
- 1. Q1: What is Serverless ? サーバレス（またはサーバーレス）とはアーキテクチ ャの名称であり、定義はあいまいなのですが、おおむ ね「サーバを意識せずアプリを構築し、実行するも の」とされます。名前に反し、サーバが存在しないわ けではない点に注意（サーバはクラウド上に存在しま す）。さらに、サーバを意識しないだけではなく、ア プリをファンクションという細かい単位で切り出して クラウド上に配置し、（サーバの立ち上げ時間ではな く）処理時間に対する従量課金制で使用できるサービ スを指してサーバレスと呼ぶことも多い（ただし、厳 密にいうと、これはFaaSと呼ばれるサービスです）。 Q2: What is Serverlessconf ? Serverlessconfは「サーバーレスアーキテクチャを用 いたアプリケーション構築における知見の共有を目的 とした、コミュニティ主導の技術カンファレンス」 （公式サイトより引用）です。2回目である今年のコ ンテンツはDay1（実際の開発がコードレベルで体験で きるワークショップ）と、Day2（各社ベンダー及び業 界の有識者が講演するカンファレンス）の2日間で構 成されています。 Serverlessconf Tokyo 2017。2年目となる今年は、500名近 い技術者が参加する大イベントとなりました。このレポ ートでは、初学者の方も読みやすいよう、まず「そもそ もサーバレスとは？」を簡単に説明した上で、2日間に及 んだこのイベントの詳細と、その魅力をお伝えします。 （SOMPOシステムズ株式会社 西野大介） Serverlessconf Tokyo 2017 REPORT | 取材・構成・文：西野大介（SOMPOシステムズ株式会社） Serverlessconf Tokyo 2017 REPORT | 取材・構成・文：西野大介（SOMPOシステムズ株式会社） DAY1 : ワークショップ 初日のワークショップは、丸一日を使ってFaaSの開発を体験するものでした。AWS/Azure/Bluemixそれぞれのベンダーごとにフロア が分けられており（Bluemixのみ会場ごと別）、各社のサービスを実際に利用しながら、具体的な機能作成を行います。ここでは、 わたしが参加したAzureのコースで過ごした一日を簡単に紹介しますので、現場の雰囲気と、開発の流れを掴んでみてください。 10:00 午前 12:00 午前 2:00 午後 4:00 午後 6:00 午後 ・DMM星野氏からの全体へ向けた挨拶のあと、AWS/Azureそれぞれのブ ースにて本日のイントロダクション開始。Azureの内容紹介はなんと英語 のみ。半分以上の講師陣の対応も英語のみ。いきなり前途多難感が...。 ・作業開始はツールインストールから。git,dotnet core,Azure Functions Core Toolsなど10種近いツールを登録。Azureアカウントは無料期間を利 用。この間に近くの方とチームを組み、相談しながら進めることに Introduction （作業は基本、githubに記載された手順をもとに各自で実施。講師はあく まで質問対応を行うのみという形式） ・サンプルをもとにシンプルなファンクションを作成。ここでは、ロー カル内でサーバを立ち上げ、「world」を引数に入れると「Hello world」 と返す単純な処理を実行させました。 ローカルでのファンクション作成 ・githubからBotのソースコードを取り込み、依存するライブラリをイン ストールしてFunctionを実行するホストを立ち上げます。そしてBot Framework Emulatorというツールを用いて、ホストのURLを設定しブラ ウザでアクセスすると、ローカルでBotが起動できます。Botは"Hello"や "Fetch me my lance"というキーワードに反応し返事を返してくれました。 ローカルでのBot実行 ・作成したファンクションをコマンドラインでパッケージし、デプロイ するとAzure上で使えるようになる...はずなのですが、チーム内3名のどの 環境でもデプロイエラーが発生してしまい、講師陣に質問したもののな かなか解消しない事態に。原因は、ライブラリが入っているモジュール が大きすぎた？不要なファイルを削除の上実行したところようやく解決。 Azureへのデプロイ ・Microsoft Bot Frameworkに接続し、先ほどデプロイしたファンクショ ンを設定。ここではMicrosoft App ID生成の処理がなぜかうまくいかず... 何度か繰り返すと通りました（原因不明ですがサーバ側の問題か）。 ・Microsoft Bot Framework上から"Hello"とタイプし、先ほどのファンク ションに設定された通りの返事が返ることを無事確認！ Microsoft Bot Frameworkへの接続 FaaSは環境構築が不要であるとは言っても、環境へのアクセスは当然必要であり、デプロイや設定変更ひとつとってもかなり とっつきにくいという印象は否めませんでした。技術的にも新たなものがどんどん取り入れられる状況でもあり、分かりやす さなどの面はもう少し分野としてこなれてこないと望めないのかもしれません。そういった感覚的な部分も含めて、触ってみ ないと分からないことは多い。その意味でも、非常に実のあるワークショップでした。 ワークショップの教材は公開されており、どなたでも試せるので、興味のある方は下記からたどってみてください。 ①ワークショップ内容：https://github.com/Azure-Samples/azure-serverless-workshop-team-assistant/tree/lang/jp ②詰まりやすい部分の解説：https://blogs.msdn.microsoft.com/kenakamu/ Day1 総括 P.1 P.2 リスニングで朝から集中力MAX いつの世もはじめはここから チャットに反応するBot Azureの管理画面 ファンクションが実行できた！ Amazon、Microsoft、IBM、Google ベンダー各社が同種のサーバレス サービスを提供している ワークショップで手を動かし、カ ンファレンスで知識を得るという 総合学習の機会を提供
- 2. Serverlessconf Tokyo 2017 REPORT | 取材・構成・文：西野大介（SOMPOシステムズ株式会社） DAY2 : カンファレンス 2日目は、全編サーバレスをテーマに贈るカンファレンス！一通り参加することで、初心者でもサーバレスの全貌が掴める、バラン スの良いセッション構成となっていました。ぜひ、このレポートで追体験してください。 ならない要素とはなんでしょうか。まずは既 存のモノリスをどう分離するかでしょう。そ してどうコンポーネントを通信させ、サービ ス境界はどんな定義とするか。コンポーネン トの粒度は。ステートレス化はどうするか。 そういったポイントを解決する際に、 AWS Lambdaは活用できます。AWS Lambdaはその構造から自然とマイクロサー ビスに親和性が高くなり、いわゆる「The Twelve-Factor App」(*1)の要素に沿った状 態になりやすくなっています。 そしてAWS SAM（Serverless Application Model）というツールが開発に役立つでしょ う。このツールにはサーバレスアプリを表現 するための標準モデルが用意されており、 APIゲートウェイの設定が自動で行われるな ど、開発の簡略化ができます。 やがて数多くのファンクションを作ったら、 AWS X-rayというツールを使ってみてくださ い。ファンクションの繋がりを可視化できる ので、機能が数百あったとしても、どこで処 理が落ちたかの判別が容易で、さらにドリル ダウンによる詳細な原因調査も可能です。 AWS Lambdaがローンチして3年。今はス タートアップだけではなく、多くの企業にお けるモダンアプリの基本コンポーネントとし て用いられるようになりました。更なるイノ ベーションを見据え、成長を続けていきます。 サーバの進化史 サーバレスとは何か。定義はいろいろある でしょうが、AWSでは「サーバを気にする ことなくアプリを構築し、実行するもの」と しています。 サーバは進化してきました。元々はデータ センター上の物理サーバを指す言葉でしたが、 仮想サーバも生まれ、さらにクラウドも出て きました。クラウドなら、よりスケールしや すく、弾力性のあるリソース活用ができ、メ ンテ作業も削減できるメリットがあります。 しかし、それだけではまだまだ制限が残り ます。仮想マシンの管理は必要で、可用性や 耐障害性の管理もある。アイドル時間でもコ ストがかかるという無駄もあります。 サーバレスのメリット そこで活用できるのがサーバレスです。ク ラウド上でアプリを使う際に、何があったら よりよいのか。キャパシティなどを気にせず アプリを構築できる環境とは何か。そういっ た議論がAmazon内であったのですが、その 答えがAWS Lambdaというソリューション でした。サーバは管理しなくてよい方が簡単 です。プロビジョニングやスケーリングの手 間から解放され、ストレージの追加検討など のヘビーなワークロードからも解放されるで しょう。その上、パッチ適用していないサー バも存在しなくなるため、よりセキュアにな ります。さらにAWS Lambdaはアイドル時 の支払いがないイベントドリブンな課金を導 入しており、処理にかかった時間ごとに100 ミリ秒単位で請求する仕組みとなっています。 企業導入事例 ここでスクウェア・エニックス社の事例を 紹介しましょう。ドラゴンクエストⅩという オンラインゲームには、写真を撮る機能があ るのですが、年末のタイミングにピークが来 ます。一昨年、撮影後に写真を見られるよう になるまで数時間かかるという事象が発生し ました。翌年に向けた対策としてサーバ追加 なども検討したそうですが、当然かなりの台 数になりますし、それによって得られる効果 は年末の一時期だけ。検討の結果、サーバ追 加ではなくAWS Lambdaを導入し、処理を パラレル化することとしました。その効果は 歴然で、一昨年の数時間に対し、導入後であ る昨年は十数秒にまで短縮しています。 AWS各種ツール活用によるサーバレス導入 さて、サーバレス導入時に考慮しなくては サーバレスの実際とAWS Lambdaの現在 基調講演 #1 Growing up Serverless | Keisuke Nishitani - AWS AWS Lambdaの従量課金制に魅力に感じ、システム移行を行いまし た。当初は既存のJavaアプリをほぼ変えずそのままで適用したのです が、多くの問題が発生しました。まず、エンハンス時に追加する部分 はマイクロサービス化し、少しずつ分けて開発することにしたところ。 その時点で、過剰に分けていないか、関係性が複雑すぎないかという 話題はあったものの、そのまま開発を継続。そして、IPアドレスの固 定化という要件が発生し、VPCの中でAWS Lambdaを動かさなければ ならなくなりました。これがとても遅いんです。結果、タイムアウト が頻発する品質となってしまい、外部向け公開NGとなりました。アプ リ側の原因としては、1シーケンスのチェーンが長かったこと。デー タに繋がるまでに6個のマイクロサービスを通る構造でした。 ということで、実行ランタイムの変更を決意しました。当初は JavaScriptにしましたがうまくいかず、TypeScriptに変更しました。 Javascriptのスーパーセットであり、Script言語でありながら静的型付 けが可能なので、レビューがしやすくチーム開発に向き、メンテも容 易。型があるためIDEで入力補完もあります。そういった特徴から、 Java開発者にとってなじみやすいものでした。 ただし、注意点もあります。まず非同期処理。非スクリプト系のチ ームはその実装に慣れるまで、それなりの学習コストと期間がかかり ました。また、JSのライブラリは栄枯盛衰が激しく、追従も大変です。 さて、最後に移行後の測定結果をお見せします。Javaアプリの時は、 Lambdaで7-10秒、VPC Lambdaで17-20秒かかっていました。それ がTypeScript化により前者は2-3秒、後者は10-13秒に短縮されました。 念のためお伝えしておくと、Javaが悪いわけではなく、Javaに向か ないアーキテクチャをとったことがそもそもの問題です。Javaの場合、 CPU高負荷のケースなら処理が速いという優位性があります。実際に 試してみたのですが、その場合Javaと比較してJSは3倍の時間がかか り、Pythonでは処理がタイムアウトするという結果となりました。 また、このアーキテクチャにしたことにより、トラディショナルな 環境を分離できたというメリットもあり、紆余曲折あったものの、最 終的には良かったと思っています。 世界はいかにしてサーバレスに至ったか。それは「よりビジネスに 直結する領域へのフォーカス」のため。システム開発の世界は他者へ の依存を強める方法に向かっています。それは、コンパイラへ依存し マシン語から低級・高級言語へ進んだのと同じです。つまり、今まで の流れの延長線上にあります。よって、サーバレスとそれ以外のギャ ップを乗り越えれば、大抵の問題の解は既に存在すると考えています。 サーバレスによくある課題とはなんでしょうか。例えば、ファンク ションの適切な粒度とは？これについては、ファンクションも機能な ので、普通にUTを実施します。つまり、テスタブルな粒度が正義でし ょう。ファンクション間のデータ受け渡しはどうする？従来の機能と 同じように、情報は引数で渡すべきですし、外部のSaaSやデータに依 存するところは個別のファンクションに切り出してまとめるべきでし ょう。そこで注意すべき点としては、データの流れは一方向にすべき と心得ること。結果が欲しければ後で取りに行くものとし、結果が必 要な処理は分離する。レスポンスは期待しないし、信用しないこと。 そうすると起こる問題もいくつかあります。例えば、ログがばらけ る。これはまとめればよいでしょう。トークンを最初に渡し、引きず りまわせばトークン検索によってトレースできるようになります。 また、ファンクションを分けすぎると遅くなるという問題。これは 構造上仕方ありません。非同期にするか、機能をクライアントに寄せ るかしかないでしょう。そもそも速度が問題になりすぎるのであれば、 極論するとFaaSに向いていないと言え、メンテナンスフリーの恩恵を 受けたいだけであればPaaSを使うべきです。 ファンクションが起動しないという問題。これについては再実行し や、多重起動で対応。この場合「べき等性」（*2）の保証は必要です。 最後にサーバレスの特徴を整理しておきます。まず、縦のスケール （処理速度）に弱く、横のスケール（並列性）には強いということ。 そして、サーバレスに明らかに向いているのは、IoTのバックエンドや ETLなどの用途。明らかに向いていないのは、即応性を求められるア プリでしょう。これまでまとめた通り、サーバレスもあくまで従来の 開発の延長線上にあります。やはり基本は大事ということです。 *2 べき等性 : 何度同じ操作を繰り返しても同じ結果を得られること サーバレスというと、何かと「サーバ管理からの解放」が謳われま す。でも本当にそこが重要なんでしたっけ？やたら新しい用語が躍っ ていますが、自分たちのサービス以外を外出しするというのは昔から 言ってましたよね？名前が変わっただけでは？「サーバ管理からの解 放」だけを主眼にサーバレス活用を進めると、ファンクションの相互 呼び出しなどが増えていき、その解決に新たな機能をかませることが 続き、そして全体像が見えなくなってシステムは複雑化するでしょう。 システムの価値とは、自分たちのシステムのために書かれたコード、 そこでしょう？だから、自分たちのアーキテクチャの中心には「サー バ管理からの解放」ではなく、コードを据えるべき。サーバレスのメ リットとは「物理マシンやコンテナが見えない」「アイドル時間中は 無課金である」「自分たちのコードを持ちこめる」この3つであると 思います。そしてその活用のベストプラクティスはまだ完全には見え ていないのです。コンポーネントも揃っていません。ただ、Azure durable functionsのように面白いものは出てきています。サーバレス は発展途上でありますが、だからこそこれからより進化するでしょう。 Session #2 サーバレスに対する誤解と本当のメリット サーバーレスについて語るときに僕の語ること | Yasuhiro Hara – SUPINF 1959年にウォルト・ディズニーが起こした放送の革新をご存知です か。当時、テレビはモノラルサウンドでしたが、彼はステレオサウン ドを届けたいと考えた。とった手段は、テレビとラジオの融合。同じ 音源をもとに、テレビから右の音、ラジオから左の音を流すという手 法により、今あるものだけでステレオサウンドを実現しました。これ は、新たな発明（invention）ではなく、革新（innovation）です。発 明は新製品を買わせますが、革新は同じ道具で新体験をもたらします。 さて、わたしはWordPressというサービスを革新する作業に関わり ました。昔から人気のサービスであり、モノリスで、多くの問題を抱 えていました。全ての解決はできないし、今のコードは極力そのまま 使いたい。その発想で選んだのがサーバレスです。実装のコア部分は PHPですが、それをそのまま使います。PHPは動的なのでリソースを 消費するため、AWS Lambdaによる静的なバージョンを作りました。 レガシーなコードとサーバレスの間には分断がありますが、それを埋 めるために機能を挟むというレガシー on サーバレスという構造です。 これが我々にとって、革新を起こす最も簡単な方法でした。 Session #3 サーバレスが起こす”革新” Retrofitting your Monolith with Serverless and Design Thinking Daniel Olson - Shifter Session #1 サーバレスにおける Java VS TypeScript Java チームが選択した TypeScript による AWS Lambda 開発 Takeshi ETOH & Sonu KIM - Riotz Works Session #4 基本原則で解決するサーバレスの課題 The mind of Serverless as a Software | Masashi Terui - Serverworks 顧客へサービス提供を行うと、管理するインフラも増える。その課 題に対する回答が我々にとってのサーバレスでした。しかし、導入し た当初はAWS Lambdaの地雷をたくさん踏みました。Lambdaが持つ、 トリガー機能には、呼ばれないことがあるというバグがあるなど不具 合がたくさん。その結果、本当に必要なところだけLambdaを呼ぶと いう「ラムダレス」で構築することに（笑）。全てのリクエストはキ ューイングされるようにし、どこかで止まっても後で動く構造をとり ました。そして、あらゆるLambdaは互いに別のLambdaを監視すると いう人間不信のような構造に（笑）。他にも、例えばSQLインジェク ションをひたすらされて（RDSではないから直接は意味がないのです が）、同時実行数の制限に引っ掛かるなんて事象もありました。また、 ひとつのLambdaだけで実行すると遅くなるので、一度SQSに保存し てから複数のLambdaで実行されるという手段をとることも。 こういった考慮がいる分、サーバレス導入はランニングコストは下 がるものの、開発コストが上がります。結果、コンペに負けやすくな るというシステム外の課題にもつながるのが悩ましいところです。 Session #5 サーバレスによるコスト課題 Biz Serverless お客様のサービスを支えるサーバレスアーキテクチャーと 開発としてのビジネスの課題 | Hiroyuki Hiki - cloudpack サーバレスという思想が何を実現していく のか。具体的にあげていきましょう。 ①スケーリングをアプリから切り離す。そ もそも、顧客へのサービス提供とインフラの 話は、本来全く関係がありません。 ②アプリのグローバルスケール化。それを 意識せず、簡単にできるようにする。これも、 アプリ開発とは本来直接関係しないものです。 ③実験の迅速化。加えて、簡単に、安くも できるようになります。 ④新技術の容易な採用。パワフルなOSSは 無料ですが、使うにはパワフルなインフラが 必要であり、オペレーションや設定を全て自 分で行うのは大変です。サーバレスなら、そ の中身を知らなくとも、ファンクションがエ ントリポイントとなり使用できます。 ⑤データアクセスの簡略化。サーバレスの 思想はイベント駆動なので、標準フォーマッ トでデータアクセスできるようしやすく、よ りデータ活用が簡単になるでしょう。 ⑥コードの再活用。マイクロサービスが疎 結合でグループ化されているのがサーバレス。 なので、それぞれのパーツを活用すれば、開 発者は自分の顧客に向けたユニークなビジネ スロジックのみ実装するだけでよくなります。 これが発展すれば、コードを書かずに開発で きるという流れもより促進されるでしょう。 そうすれば裾野はさらに広がります。 サーバレスが解決する生産性のジレンマ 生産性の定義と計測の難しさ 生産性の向上、それはソフトウェア開発に おいて重要です。生産性は「インプットした ものに対するアウトプット率」で測られます。 しかし、それを計測することは、農業のよ うな産業では容易なのですが、ソフトウェア 業界では困難です。よって生産性計測におい ては、以下2点の観点を適用すべきでしょう。 ①Developer Productivity:開発側の生産性。 エンドユーザに対しどれだけタイムリーに届 けられるかということ。例えば、開発開始か らリリースまでにどれくらい時間を費やした か、そういうことを計算すればよいでしょう。 ②Software Productivity:ソフトウェアそ のものの生産性。B2Bでは、そのソフトウェ アを活用することによってエンドユーザの業 務の生産性がどれだけ向上したか。そこがも うひとつの指標になるでしょう。 開発の生産性を向上させる開発手法 開発側の生産性の観点で述べると、その向 上に寄与する様々な開発手法が出てきました。 開発プロセスはウォーターフォールからアジ ャイルにスイッチし高速化、そしてDevOps 開発手法を導入した自動化も進められていま す。クラウドを活用したインフラのアウトソ ースにより環境管理は容易になり、マイクロ サービスを適用すれば細かい単位で作業でき るようになり効率も向上しました。 それでも上がらない生産性 さて、これだけの進化は、どのように生産 性に影響を及ぼしたでしょうか。IT製品は80 年代から増えてきましたが、70年代から現代 にかけて、実は生産性が下がった状態が続い ています。日本だけでなく英米加も。ツール や手法がパワフルになっているというのに。 なぜか。それは、開発が難しすぎる、複雑 すぎるということ。開発においては、毎回、 スピード・スケーリング・事務の最適化など が主題にあがります。それぞれのチームは毎 度、初めてのことにように対峙しているのが 現状です。そしてデータの再活用もできてい ません。アプリで意味のある再活用をしよう とすると、ツールはもっと複雑になってしま うというジレンマがあります。 サーバレスが解決すること ここにあげた課題を解決し、生産性を向上 させるには、インフラを抽象化してアプリか ら切り離すべきです。それはサーバレスアー キテクチャの導入によってなされるでしょう。 基調講演 #2 Software Productivity and Serverless | Nick Gottlieb - Serverless,inc. Serverlessconf Tokyo 2017 REPORT | 取材・構成・文：西野大介（SOMPOシステムズ株式会社） *1 The Twelve-Factor App : 米企業"Heroku"が提唱する、望ましい形でクラウドネイティブアプリを構築するための方法論 Day2 総括 サーバレス一色、かつその中でもベンダー側/導入企業 側、概念説明/事例紹介、肯定意見/否定意見など多種多 様に揃えられていたため、サーバレスの知識整理に大変 役立つ内容でした。その上お祭り感があり、スタッフの 方々が熱い！紙幅の都合上泣く泣くカットしたセッショ ンや、ノベルティ配布しまくる楽しい各社ブース、さら に思いの詰まったLTなど、載せきれなかったすばらし い要素はたくさんありますが、ここでは、閉会時に代表 の吉田さんが語られた印象的な一言を残して終わります。 「去年はサーバレスをクラウドというメインストリーム に対するカウンターカルチャーという位置づけでとらえ ていた。今年はそうではなく、サーバレスこそがメイン ストリームになるのではという気持ちで開催した」この カンファレンスに参加して、わたしもそう感じました。 P.3 P.4