先週のAWS関連ブログ〜9/11(日) - AuroraリーダーエンドポイントやServerless Architecture Talksなど

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

涼しくなってきましたね。先週からオフィスの椅子を入れ替え43インチ4Kモニタを配備したらだいぶ快適になりました。

それでは行ってみましょう。

AWS公式

1. Amazon Auroraにリーダーエンドポイントが追加されました – 負荷分散と高可用性向上 –

  • 特定のリードレプリカのエンドポイントに接続するのでなく、このリーダーエンドポイントを利用することで、接続先がマスターに昇格した場合は別のレプリカのIPに解決されたり、特定のAZに配置したレプリカが利用できなくなった場合に他のレプリカに接続されるようになったりと、アプリから透過的に利用でき、可用性や負荷分散が実現される機能です。

リンク：Amazon Auroraにリーダーエンドポイントが追加されました – 負荷分散と高可用性向上 – | Amazon Web Services ブログ

2. AWS SDK for C++がGAに

  • 数多くのバグ修正を経てAWS SDK for C++がバージョン1.0になりました。
  • NuGet経由で入手できるようになったり、セマンティックバージョニングによりマイナーアップデートによってビルドが破損しないよう担保されています。

リンク：AWS SDK for C++ – 本稼働環境で使用する準備ができました | Amazon Web Services ブログ

3. CodeDeployのデプロイを監視してCloudWatch Eventsでトリガ発行が可能に

  • CodeDeployによるデプロイイベントを監視するようになったので、デプロイなどのイベント発生時にCloudWatch Eventsからトリガを発行することが可能になりました。
  • CloudWatch Eventsは現状「Lambda」「Kinesis streams」「SQS」「SNS」「ビルトインターゲット」にトリガ発行できるので、工夫次第でさまざまな後続アクションを作成できます。

リンク：Monitor and React to Deployment Changes in AWS CodeDeploy with Amazon CloudWatch Events

4. CloudFrontがHTTP/2をサポート

  • ワンクリックでCFのディストリビューション単位にHTTP/2を追加可能になりました。

f:id:yoshidashingo:20160912121732p:plain

リンク：Amazon CloudFront now supports HTTP/2

AWS関連

5. Serverless Architecture Talks

  • 目黒のAWSにおいてGunosyさんとクラメソさん共催で「サーバーレス」に関するセミナーイベントが開催されました。
  • 実践的なセッションが多かったようです。

speakerdeck.com

speakerdeck.com

speakerdeck.com

gunosy-beer.connpass.com

http://minamo173.hatenablog.com/entry/2016/09/12/Serverless_Architecture_Talksに参加しました%E3%80%82minamo173.hatenablog.com

dev.classmethod.jp

togetter.com

6. ECS を利用したオフラインジョブの実行環境

  • クックパッドにおけるECSクラスタ上で実行されるオフラインジョブの実行環境の話です。
  • barbeque(ジョブキュー)→hako(Dockerコンテナをデプロイするヤツ)でDockerイメージをデプロイする先のECSのホストEC2が足りない場合にエラーを発生し、それを受けてAuto Scalingグループのdesired capacityを増やしてスケールアウトする仕組みを組んで使っているそうです。
  • スケールインの仕組みはジョブの種類ごとにさまざま工夫をしているようなので、統合的な仕組みがECS側に組み込まれると良さそうに思いました。

techlife.cookpad.com

その他

7. GoogleがApigeeを買収

  • APIゲートウェイツールのApigeeがGoogleに買収され、GCPに組み込まれる予定とアナウンスされています。
  • AWS API Gatewayと同じようなサービスを考慮しているものと思われます。
  • これからこの分野はKongのようなAPIのMarketplaceまでエコシステムを整備できるかどうかという感じになるのではないでしょうか。

リンク：Google Cloud Blog - News, Features and Announcements

www.publickey1.jp

jp.techcrunch.com

今週は以上です。

Building Serverless Machine Learning Models in the Cloud (ServerlessConfセッション紹介)

ServerlessConf

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

第4弾は海外のスピーカーの紹介です。エンジニアでありジャズミュージシャンでもある Alex、インタビューの最後ではコード(Code)とコード(Chord)の類似点なども聞いてますのでぜひじっくりお読みください。

プロフィール

  • 名前: Alex Casalboni
  • 会社: Cloud Academy, Inc.
  • 職種: シニアソフトウェアエンジニア

f:id:yoshidashingo:20160909191456j:plain

アレックスは Cloud Academy のシニアソフトウェアエンジニアでありジャズミュージシャン。好きなことは JavaScript や Python でウェブアプリケーションや機械学習モデル、サーバーレスなマイクロサービスを作ることです。

Quick Chat

---- 日本に来てくれるということでありがとうございます、来日中にやろうと思ってることはありますか？

はい、10/6まで東京の美しい場所に宿泊する予定なのと、途中京都と大阪をちょっと駆け足で回ってくる予定です。

日本に行くこと自体が初めてなので、早く日本中の古式ゆかしい文化に触れてみたいです。

---- それはよかった、ぜひ楽しんでください。では ServerlessConf Tokyo でのセッション概要を教えてください

私のセッションではデータサイエンティストが機械学習モデルを本番環境にデプロイするためのチャレンジについてお話します。

A/Bテストや高スケーラビリティや高可用性を備えた、Pythonライブラリとマルチモデルでできたシステムの参照実装や例についても触れます。

また、伝統的なデプロイ戦略の限界について語りながら、サーバーレスコンピューティングでデプロイのワークフローがいかに単純にできるかデモもお見せします。

---- たしかに、正しいモデルを構築するのって非常に難しい課題ですよね。サーバーレスな構成だとこのプロセスをもっと早く実現できるってことですか？

私は日々とても優秀なデータサイエンティストたちと働いてるのですが、サーバーレスな技術を使うことで彼らはすばやく仕事にとりかかれて、最高の機械学習モデルを構築するという重要な目標にフォーカスすることができています。

サーバーレスな手法で考え、開発することで、彼らはインフラやオペレーション、スケーラビリティ、可用性などなどに関連したほとんどの問題から解放されます。と同時に、彼らはとくに助けなしに、A/Bテストやモデルの改善をくわえてデプロイすることができます。それは最終的に、チーム全体や会社全体にとってより高品質な結果を残すことになります。

---- ちまたにはたくさんの機械学習のサービスやフレームワークツールがありますが、どれを使えばいいか選定するためのオススメの方法はありますか？

その選択はさまざまな要因に依存します。

  1. そのアプリケーションやシステムが現在どこで稼働しているか ほとんどのクラウドベンダーが多大なる努力をもってロックイン障壁を取り除いてはいるが、MLaaS オプションはたいていの場合そのクラウドプラットフォームの他のサービスと合わせて使いやすいように統合されていたりするのも事実です。明らかなネットワークの近さという利点を評価に加えなかったとしても、現在利用中のクラウドベンダー上のサービスというのは最優先の選択肢ではあります。

  2. どのレベルまでのコントロールを求めているかあるいは必要としているか すべての MLaaS オプションはモデル設計における異なったレベルのコントロールを提供しています。たとえば、モデリングのロジックやデータ処理によりディープなコントロールが必要な場合もあれば（例：Azure Machine Learning）、その他の多くの場合は単純なブラックボックスなインタフェースで十分な場合が多いでしょう（例：Google Prediction API）。個人的には完璧な MLaaS ソリューションは可能な限り抽象化された状態で代替案を広く網羅しているべきで、Amazon Machine Learningはその望むべき方向に向かっていると思います。

  3. ほんとうにMLaaSが必要かどうか あなたがデータサイエンティストである場合は特に、頻繁にモデルを完全にコントロールする必要があるでしょう。これらのケースでMLaaSのソリューションはあなたのニーズを満たさないかもしれないですが、そんなときはクラウドコンピューティングのメリットを活かしてサーバーレスなクラウドに機械学習のモデルをデプロイするといいでしょう、たとえば AWS Lambda や Azure Functions 、 Google Cloud Functions などです。

ここらへんのサーバーレスと機械学習についてはもう少し詳しく 個人ブログ に書いておきました。

blog.alexcasalboni.com

---- ありがとうございます。ところで普段仕事ではどんなことをやってるんですか？

私は2013年に非常に初期の従業員として Cloud Academy にジョインしました。つねに情熱をもってウェブ開発や Cloud Academy を立ち上げていくことはとても楽しかったです。チームが急速に成長した今はいくつかの面白い役割をカバーしているという状況です。 シニアソフトウェアエンジニア として私は新しいクラウド技術を学ぶ学生を手助けする目的で新しい教材を設計し、作成しています。また クラウド・エバンジェリスト として新しい学生やITプロフェッショナルたちにクラウドコンピューティング、とくにサーバーレスの部分で最適のアプローチを見つけてもらうための動機づけや支援ができてハッピーです。

---- ジャズが好きなんですね？コード(Code)とコード(Chord)で似ていることってあるんですか？

ジャズが大好きで、サキソフォンとピアノ奏者を12歳からやっています。両親もミュージシャンだったのでこの素晴らしい情熱を共有していました。

とても似ている点でについてですが、私はコーディングを15歳からやってますが、それ以来つねにこの2つの世界はとても関係が深いと考えています。どちらも個人的な情熱や創造性、問題解決を共有しあう手段であると同時に、そのためにはたくさんの技術的なスキルや自然の法則や構造的な思考、ロジックやサイエンスが求められるという点です。

---- ありがとうございました、会えるのを楽しみにしてます！

ありがとうございました、私もほんとうにあなたやServerlessConfの参加者のみなさんにお会いできることが楽しみです。

イベントでは気兼ねなくお声がけください。Twitter でもどうぞよろしくお願いします。

Firebaseを使ったサーバーレスWebアプリケーション開発 (ServerlessConfセッション紹介)

ServerlessConf

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

第3弾はフロントエンド開発者であるきはるさんです。

プロフィール

  • 名前：佐々木季羽る Kiharu Sasaki
  • 会社名：freelance, Section-9
  • 職種：Frontend Developer

f:id:yoshidashingo:20160907073136j:plain

SIerで通信系システムの開発に携わった後、コンサルティング会社にて金融系エンタープライズシステムを担当。フリーランスとして独立後は、Webアプリケーション開発を中心に活動中。流しのフロントエンドエンジニア。Section-9メンバー。

Quick Chat

---- ServerlessConf Tokyoでのセッション概要を教えてください

Firebaseは、Googleが提供しているバックエンドサービスです。

アプリケーションに必要なサーバー、DBの構築や運用が不要なのはもちろん、データに連動してREST APIが自動で作成されるリアルタイム同期データベース、各種プロバイダでのユーザー認証、オフライン処理、画像や動画のアップロードが可能なストレージ、ホスティングまで、バックエンドに必要とされるほぼすべての機能を備えたFirebaseを使うことで、フロントエンドの開発に注力することが出来ます。

モバイルバックエンドサービス(MBaaS)として語られることが多いFirebaseですが、今回はWebアプリケーションにおける利用方法についてお話します。

---- 最近フロントエンドで使ってるのってどういったフレームワークですか？

最近のフロントエンド界隈では、Reactの人気の高さや、Angular2への期待感が何かと話題です。今後もしばらくはこの2つが話題の中心だと思います。また、「リアクティブ」「コンポーネント」といったキーワードも重要なので、フロントエンド以外の方も抑えておくと良いです。

私自身は、業務ではAngular1、Vue.jsを使っていて、過去にはBackboneも使っていました。Reactの導入も検討中です。(※個人的にはAngular2とVue.js推しです)

フロントエンドは移り変わりが激しいとよく言われますが、それはWeb標準の変化速度が早いせいでもあり、高レイヤーな技術ほど影響を受けるのは必然とも言えます。ですので、今後もWebが進化し続ける限り、どれか1つのフレームワークに落ち着くことはないだろうと思っています。

---- Firebaseがよい点は具体的にどういうところですか？

まず、とにかく簡単だという点です。DBのデータ取得がJSで1行で書けるくらいに簡単です。ソーシャルアカウントでのユーザ登録やログイン処理も、数行で実装出来てしまいます。

機能面で決定的なのは、オフライン処理とリアルタイムデータ同期です。昨今では、Webアプリケーションであってもネットワーク接続に依存せず、オフラインでもユーザが操作を続けられ、ネットワークが復帰した際にはスムーズにデータが同期されるといった、モバイルアプリに近いUXを求められる流れ（プログレッシブウェブアプリ）が来ています。実際これをWebで実現するのは容易ではありませんが、Firebaseを使えば開発者が意識することなく実現出来てしまいます。

---- Firebase以外によくバックエンドとして利用するサービスはどういうものがありますか？

業務ではBaaSを利用すること自体が稀で、機能ごとに外部サービスを組み合わせて利用することが多いです。モバイル(MBaaS)であれば国産も含めいくつかありますが、WebのBaaSは選択肢がかなり限られるかと思います。

---- フロント/バックエンド全部やってると実際のところ工数配分ってどのくらいですか？

SPA(シングルページアプリケーション)でない案件だと半々くらいです。デザインも担当している案件だと、UIに一番時間がかかっているかもしれません・・・(^^;

---- フロントエンドからインフラまでプロレベルで1人で見られる人って実際多くないと思うけど、きはるさんのような人がもっと増えて欲しいですか？

私自身はインフラ部分は必要最低限でしか関わらないようにしているので、フルスタックとは言えないのですが、フルスタックな人（またはそれを目指している人）は、CTOなどテクニカルのトップにでもならない限り、ただの器用貧乏で終わってしまうので勿体無いかな、と。なので増えなくてもいいと思います(笑)

ただし専門分野以外の知識がゼロなのは論外だし、最近ではフロントエンドとサーバーサイドの境界線も曖昧で、兼務している人も多いので、関連性が強い領域についてはある程度守備範囲を広げていく必要もあり、そのためには日々の情報収集や学習が大切だと思っています。

---- ありがとうございました、当日はもっと突っ込んだ話を楽しみにしています。

ありがとうございました。

まとめ

フロントからバックエンドまですべて面倒を見る場合に、すべてを自前で準備するのは限界があります。そのためにフレームワークやBaaSのサービスを使うほうが開発生産性の面で有用なのは明らかです。重要なのはキャッチアップし続ける姿勢ということでしょう。

開発体制やFirebaseの運用上の注意点などについては今回お聞きしませんでしたので、興味のある方はServerlessConfに参加してください。

tokyo.serverlessconf.io