JAWS-UGアーキテクチャ専門支部でServerlessConfのレポートをしてきた

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

掲題のとおり、最近のサーバーレス界隈の話やServerlessConfのレポートを話してきました。

jawsug-arch.connpass.com

当日のスライドはこちらです。

www.slideshare.net

参考情報のURLは以下の2つです。

martinfowler.com

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

その他の方たちの発表

Apexで複数環境のLambda関数をデプロイする話

speakerdeck.com

新卒新入社員だけで仮想プロジェクトやってます

www.hands-lab.com

【濃縮版】新時代の幕開け、サーバーレスアーキテクチャの衝撃! 〜開発・運用・セキュリティ・コストがどう変わる?〜

www.slideshare.net

Python Serverless Microframework for AWS(Preview)のchaliceを使ってみる

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

Python Serverless Microframework for AWSという、Serverless Frameworkに似たWeb APIのフレームワークがPreviewリリースされたのでチュートリアルどおり試してみます。

Preview the Python Serverless Microframework for AWS | AWS Developer Tools Blog

※ GitHubはこちら

github.com

1. インストール

$ sudo pip install chalice

2. 新規プロジェクト作成

$ chalice new-project demo
$ cd demo

3. デフォルトの定義のままデプロイして確認する

  • 定義ファイル app.py を確認する
$ vi app.py
  • デフォルトで以下のように定義されている
from chalice import Chalice

app = Chalice(app_name='demo')


@app.route('/')
def index():
    return {'hello': 'world'}

  • デプロイする
$ chalice deploy
Initial creation of lambda function.
Updating IAM policy.
Creating deployment package.
Lambda deploy done.
Initiating first time deployment...
Deploying to: dev
https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/
  • エンドポイントにアクセスしてみる
$ curl https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/
{"hello": "world"}
  • 存在しないパスにアクセスしてもエラー
$ curl https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/AWS/hello
{"message":"Missing Authentication Token"}

4. 定義ファイルにAPI機能を追加してデプロイする

  • 定義ファイル app.py を編集する
$ vi app.py
  • 以下のように定義にAPI機能を追加する
from chalice import Chalice

app = Chalice(app_name='demo')


@app.route('/')
def index():
    return {'hello': 'world'}

@app.route('/{name}/hello')
def hello(name):
    return {'hello': name}

  • デプロイする
$ chalice deploy
Updating IAM policy.
Updating lambda function...
Regen deployment package...
Sending changes to lambda.
Lambda deploy done.
API Gateway rest API already found.
Deleting root resource id
Done deleting existing resources.
Deploying to: dev
https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/
  • エンドポイントにアクセスして機能追加されたことを確認する
$ curl https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/
{"hello": "world"}

$ curl https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/AWS/hello
{"hello": "AWS"}

$ curl https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/serverless/hello
{"hello": "serverless"}

5. ログ出力して、確認してみる

  • 定義ファイル app.py を編集する
$ vi app.py
  • 以下のようにprint文を追加してログを出力するようにする
from chalice import Chalice

app = Chalice(app_name='demo')


@app.route('/')
def index():
    return {'hello': 'world'}

@app.route('/{name}/hello')
def hello(name):
    print('I want to log {}'.format(name))
    return {'hello': name}

  • デプロイする
$ chalice deploy
Updating IAM policy.
Updating lambda function...
Regen deployment package...
Sending changes to lambda.
Lambda deploy done.
API Gateway rest API already found.
Deleting root resource id
Done deleting existing resources.
Deploying to: dev
https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/
  • ログ出力を追加したAPIにアクセスする
$ curl https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/logme/hello
{"hello": "logme"}
  • ログを確認する
$ chalice logs --num-entries 2
2016-07-12 06:45:12.099000 b929c8 START RequestId: beb5562b-47b0-11e6-97f7-2345ee85dba4 Version: $LATEST
2016-07-12 06:45:12.100000 b929c8 I want to log logme
2016-07-12 06:45:12.101000 b929c8 END RequestId: beb5562b-47b0-11e6-97f7-2345ee85dba4
2016-07-12 06:45:12.101000 b929c8 REPORT RequestId: beb5562b-47b0-11e6-97f7-2345ee85dba4   Duration: 0.40 ms Billed Duration: 100 ms    Memory Size: 128 MB    Max Memory Used: 15 MB

6. まとめ

Serverless Frameworkであればステージの指定やプロファイルの切替、エンドポイントやリソースの削除などもできますが、こちらのPython版はPreview版なので、まだ機能的にはさほど揃ってないようです。

先週のAWS関連ブログ 〜7/10(日) - Infrastracture as Code、WordCamp Kansaiなど

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

週末にKINGSGLAIVE FINAL FANTASY XVを観てきました。FFXVメディアミックスのいちコンテンツではありますが、FFをプレイしない人でも十分に楽しめる「ストーリー」「映像クオリティ」でした。9/30が楽しみです。

ということでさっそく行ってみましょう。

AWS公式

1. AWS Black Belt Online Seminar「Parse.comからAWSへのモバイルアプリの移行」の資料公開

  • 2017年1月に閉鎖されるParse.com上のサービスをAWSに移行する方法
  • マッピング
    • Parse ServerとMongoDB→EC2あるいは元からライフサイクル管理するようにBeanstalk上で構築・管理
    • Parse Push → Amazon SNS mobile push
    • Parse Analytics → Amazon Mobile Analytics
    • Parse Users → AWS Cognito User Pools
  • Pushの移行が特に手間がかかる(Push実装自体手間がかかるのでしかたない)

www.slideshare.net

aws.typepad.com

2. [OpsJAWS: やってみようシリーズ] Sumologicの検索(CloudTrailのログ解析)

  • パートナーによる寄稿シリーズ「OpsJAWS: やってみようシリーズ」、Sumologic第2弾
  • Sumologicに取り込んだCloudTrailログを検索したり、さらにノイズを取り除いて自分が見たい情報を見られるようにするためのクエリ方法の解説

aws.typepad.com

AWS関連

先週は Infrastructure as Code のイベントやWordCamp Kansai 2016などでAWS関連のセッションなどがありました。

Recruit Technologies Open Lab #03 テーマ:Infrastructure as Code

www.youtube.com

3. Infrastructure as Code のこれまでとこれから

  • 現状、以下の4層のコンセンサスのうち、Infrastructure as Codeのスコープは「Infrastructure Definition Tools」と「Server Configuration Tools」
    • プログラマブルにリソースを提供する動的インフラプラットフォーム(Dynamic Infrastructure Platform)
    • インフラレイヤーをプログラマブルにプロビジョニングするインフラ定義ツール(Infrastructure Definition Tools)
    • いわゆるConfiguration Managementであるサーバー設定ツール(Server Configuration Tools)
    • Orchestrationレイヤーであり、ライフサイクル管理に欠かせないインフラサービス部分(Infrastructure Services)
  • 今後はDynamic Infrastructure Platform選択肢の増加や、コンテナ技術によりホストマシンとコンテナそれぞれにスコープが分離し、プロビジョニングの単純化がされる。また、Microservices化により各サーバーのコンポーネントは単機能化するがシステム内のインフラの数は増えて複雑化するので、Infrastructure Services(Orchestration)がより重要になる。

speakerdeck.com

4. Infrastructure as Code

  • コード化により、インフラにもアプリ開発のベストプラクティスが適用できるようになった。コードの再利用やCIや自動テスト
  • Reproducible Build(ビルドの再現可能性)が重要であるので、コード化で重要なのは実は単なる構築の自動化ができるということではなく、あるべき状態をコード化して冪等にそれを再現できること。

speakerdeck.com

5. Infrastructure as Codeと組織文化

  • コンウェイの法則のとおり、アーキテクチャは組織のコミュニケーション構造を反映したものになるので、組織構造抜きには考えられない。
  • インフラとアプリが分離されたチーム構成を取ることが多いが、垣根が存在する弊害がさまざまある。
  • 組織構造(3-1)で示すとおり、インフラとアプリは開発チーム内にいて、セキュリティや標準化など、デリバリーのリードタイムとは別の軸で専門的に動くもののみ共通的な横断チームとすることが提案されている。
    • 自分も大いに賛成で、本来サーバーの購入やキッティング、ラックの準備や場所の割当てなど社内の一箇所で慣れた人がやらないと非効率だしなにより統制が取れなかったという事情はあったと思うが、仮想化やクラウドを基盤にして、アプリ開発のベストプラクティスをインフラにも適用するのであれば、組織構造もそれに合わせて変化させる必要があるだろうと思う。

slide.meguro.ryuzee.com

6. 運用・監視もコード化する。開発者が監視まで考える方法論

  • 何を監視するか継続的に考えながら実装するのが大事なので、インフラ任せにならずアプリによって最適なものを設定を考え、必要に応じてアプリ側でプラグインを自分で作ったりするのも大事。
  • 誰でも監視設定できるのが理想

運用・監視もコード化する。開発者が監視まで考える方法論

7. プロビジョニングツールはMakeで決まりだろ

  • 宣言的記述による差分適用により冪等性を担保するというアプローチは実際ツラいこともあり、そもそも複雑なサーバーの状態管理をするのではなく単機能化して「組み合せ方」を考えるのはどうか

speakerdeck.com

ここまで見るとそれぞれのセッションの実践部分が、mizzyさんの4層のコンセンサス内容で見事に抽象化して説明してあるなと思いました。

WordCamp Kansai 2016

8. 「ざっくり分かる WordPress サイトのチューニング」を WordCamp 2016 で発表してきました。

  • チューニングに必要なのはまず「計測」、そして手間と効果を考えた「キャッシュ」戦略
  • 代表的な計測方法や、レイヤーごとの代表的なキャッシュ方法を解説

blog.shin1x1.com speakerdeck.com

9. AWS+WordPress.SkeletonでスケーラブルなWordPressサイトをつくる

  • WordPressのスケーラビリティを確保するのは複数ノードにおける「メディアファイルの同期」と「コアやプラグインやテーマの更新」という観点で難易度が高い
  • メディアファイルはS3などにオフロードすると良い
  • 更新はWordPress.Skeletonを使うことで、PHPのComposer(パッケージ管理システム)で依存性も含めて管理が可能、実際のアップデートはBlue-Greenでダイナミックにバージョンごと切り替えを行う。
  • バージョンによりDBのマイグレーションが必要な場合や言語ファイルなどについては依然として課題は残る。

speakerdeck.com

10. WordPress RESTful API & Amazon API Gateway

  • WordPressをヘッドレスCMS化するにあたり、APIのベストプラクティスの適用(キャッシュやスロットリング)は難しいが、API Gatewayを使うことで、WordPressおよびそのサーバー管理と切り離された切り離されたAPIからサーバーレスにデータの配信などを行うことでスケールさせることが可能。
  • WordPressをフロントに利用するパターンや、JavaScript経由でデータのみ非同期に連携する方法が解説されている。

www.slideshare.net