AWS Summit2018レポート(2) サーバレス関連の話題をひたすら追った

年に一度のAWS Summit TOKYO!
今年もついにやってきました!もう語彙力もクソもありませんが、やってきたんですよ!
今回も会場はいつもの品川プリンスホテルからお送りしています。

筆者はWorkshipmagazineの裏側で働いてるふりをしているバックエンドエンジニアの土屋(愛称:つちやの人)です。
今回はAWSのイベントをECS(Elastic Container Service)やEKS(Elascic Kubernetes Service)のコンテナサービス・や東京リージョンへの進出が発表されたFargateなどのServiceを中心としたセッションを聞き、その内容をまとめました。

この記事は「サーバレスってそもそもなんすかwww」「サーバーってなんすかwww」っていう感じの方向けではなく、「サーバレスを導入しようか迷っているんだけど……」という具体的な検討フェーズにいる方へ向けた内容となっております。
今回のセッションたちがお役に立てたなら嬉しいです!

(もうちょっとビジネス寄りのレポートが読みたいという方はこちら↓↓)

Amazon ECS を活用した、転職サービス「MIIDAS」の AWS 移行事例

まず訪れたセッションは、「Amazon ECS を活用した、転職サービス『MIIDAS』の AWS 移行事例」です。

転職求人アプリのMIIDAS(ミイダス)を運営するのは、パーソルキャリア株式会社。このアプリは、書類選考が終わっているのですぐに面接をできるというポイントが話題を呼びました。

サーバーの負荷をどう解消するか

MIIDASではサービスが軌道にのるにつれ、サーバーの負荷が上がっていき、インフラの作業に終われ機能開発を行うことが難しくなり、開発チームは以下の問題を定義したといいます。

  • サーバーが整理されていない
  • バックアップサーバに処理が集中
  • ほぼ単一のサブネットに集中

また移行前の課題として

  • スパイクを防ぐ
  • 手のかかる作業をやめて開発に集中したい
  • 構成 / 構築を簡単にしたい

という課題がありこれらの解決を行うためインフラの再構成を行いました。

移行時の設計方針

また移行時の設計方針として次の項目を挙げました。

  • 既存のアプリケーションはなるべく手を出さない
  • 役割を整理してシンプルな構成にする
  • 可能な限りマネージドサービスを利用

MIIDASの場合、開発環境がDockerで構築されていたため、ECSへの移行をしました。

移行して得たメリット

  • ローカルから本番環境まで動作が統一された
  • 癖のあるミドルウェアでも、コンテナで導入しやすい

というメリットが与えられたそう。
また以下のような気付きもあったと語ります。

  • オートスケーリンググループの設定などがCloudFormationで上書きされる
  • 設定箇所が多すぎて難しい
  • デプロイ手順が増え多く感じる

総合評価としてメンテナンスが楽になったことや機能開発を行う時間が増えたようなので移行は成功という判断をしたようです。

 

Building Enterprise – Grade Serverless Apps エンタープライズ・サーバーレスアプリケーションの実現

次に訪れたセッションは「Building Enterprise – Grade Serverless Apps エンタープライズ・サーバーレスアプリケーションの実現」です。AWSのティム・ワグナー氏の講演が同時通訳されました。

現代のサーバレスで主要なトレンドには次のような項目が述べられます。

  1. 自分でコーティングしない、マネージド・サービスの台頭
  2. マイクロサービスの適用
  3. ストリーム処理
  4. サーバレス・イベント駆動型のアーキテクチャ
    (常に仕事を待っている状態はなくなった)

直近ではLambdaによって以下のようなメリットが得られます。

  • サーバー管理が不要
  • 柔軟なScaling
  • 高可用性
  • アイドル時のリソース管理が不要

これらのメリットがうまれ、マネージドサービスを使うことによりサーバーの管理が減り機能開発に集中することができるとのことです。

またサーバレスをより効果的にする方法を詳しく見て見ましょう。

1 . パターンを使う

AWSの製品を組み合わせれば、様々なメタパターンで実装することができ、重要なことは「車輪の再発明をやめる」ことである、マネージドサービスで利用できるものはマネージドサービスを利用する

2 . プロ並みにスケール 同時実行・スロットリング

API キー レベルのスロットリング 使用量プランで構成可能でメソッドレベルのスロットリング ステージ設定で構成可能なので必要に応じて設定する
またAWSの管理者アカウントレベルのスロットリング 実行制限を引き上げることもできるので、足りない場合は申請してほしいとのこと

3 . 重要なSceOps パーミッション セキュリティと認可 ファンクションは何を誰が呼び出されるか

重要なポイントは誰が設定することができるか、なにか起きたことを把握できるかを考えることが重要で、
ざっくりまとめると以下の3点に気をつけて設定するべきで

  • リソースポリシー : 誰を家に招待するか
  • 実行ルール : 子供が損で良いものはなにか
  • ロール : 職場にいる?家にいる?(誰がファンクションを作れるか・誰が再設定できるかなど)

これらの3点を常に考え設計してほしいとのことです

4 . サーバレスアプリケーションのビルド・テスト・デプロイ

AWScodeCommit or Github → AWS codeBuild → AWS code build → CloudFunction → AWS CodeDeploy

この流れでビルドするのが一番シンプルな構成とのことです。

またローカルの開発環境を構築するにあたって、AWS SAM Localをつかってローカルでサーバレス環境を実行できるので、Lambdaを使用する際はぜひ使用してみてほしいとのこと。

5 . アプリケーションとして考える

ここで知っておくことはLambdaをファンクションのモニタリング方法を知っておくことが重要とのことで、
Lambdaが実行されるためには

  1. コードのダウンロード
  2. 言語のランタイムの開始
  3. コードのロード
  4. init処理の実行
  5. リクエスト実行

この順番で実行されるため、ファンクションの実行を効率化するためには

  • コードをできるだけ小さくする
  • ライブラリ / パッケージの読み込みを少なくする
  • 低頻度利用のファンクションと高頻度の利用のファンクションのmix構成を検討する
  • 使う言語ごとのバージョンを考える・最適化を行う

などで対策することによりLambdaの実行時間を短くすることができます。

PlayStation™ Network での Container 導入事例

SIE(株式会社ソニー・インタラクティブエンタテインメント)によるセッション「PlayStation™ Network での Container 導入事例」では、フルスクラッチでCICD環境での構築を行った事例が紹介されました。

SIEではPlayStation™ Network を世界中に展開しており、そのインフラをAWS上で展開していてなんとEC2だけで数千のインスタンスが立ち上がっているとのこと。

世界中にサービスを展開しているので、デプロイの際になんと1日以上かかることもあり、機能のリリース数が限られてしまうことから改善しようという課題からインフラの見直しが始まりました。

ECSの導入を決定したポイントとしては

  • 学習コストが低い(トレードオフ : 機能が限られる)
  • 高品質
  • AWSServiceとの連携

というポイントを特に強みだと感じ、その当時のEKSは発展途中なので一旦見送りになりました。

ステージング環境も構築し、ステージング環境と本番環境の差分はインスタンスの台数が少なく、環境起因の問題を解決するための使用することをメインとして構築したとのことです。

大切なのは、Dev Ops Sec AWSの人を巻き込みながら移行し、それぞれをポジションの人にはそれぞれの思いがあるから、説明していくこと。

最終的に、インフラの移行を行った結果デプロイにかかる時間が20分にまで短縮されたそうです。

 

ビズリーチ社のサービスを支える Amazon ECS と AWS Batch の活用事例

最後に訪れたセッションは「ビズリーチ社のサービスを支える Amazon ECS と AWS Batch の活用事例」です。

今回はHrmos(ハーモス)の事例を紹介してくれました、Hrmosは人事向けの支援ツールで人事データを可視化することにより、人事を支援できる企業向けツールです。

Hrmosではコンテナ化した際のメリットとして次の5点を挙げました。

  1. アプリケーションの成果物が開発環境・本番環境・ローカルでも同じ
  2. リソースを共有
  3. 水平スケールが容易
  4. インフラコード・コンピューティングリソースからのアプリケーションの分離
  5. Immutable Infrastucture

中でもアプリケーションの成果物が同じというころがとてもよく、差分がないというポイントから開発がとても楽になったとのこと。

バッジ処理もEc2で実行していたため、今回はAWSBatchへと切り替えて以下のメリットが得られました。

  • EC2の管理が不要
  • スポット処理にも使える
  • リトライ処理が自動
  • 料金は処理中の時間のみ

ただCloudwatch + Lambdaでも同様のことは再現できるが、Lambdaだと上記で記述した実行時間の問題があるためPDFがアップロードされた際にウィルスをチェックする部分を任せて、構築を行っています。
しかしAWS Batchでも残念なところはあって、

  • CloudWatchで処理結果のMetricsが見れれない
  • 起動までに時間がかかる
  • リアルタイム処理には向かない

というところがAWS Batchでは残念なところである、と述べていました。

Hrmosではコンテナ内の監視ではDatadogを使用し運用しているとのことです。

まとめ

サーバーレスは非情に早いペースで浸透しており、AWS上ではかなり優良な選択肢として挙げられるものとなりました。

またアプリケーション(プロダクト)の開発に集中したい・車輪の再開発はやめようということをさまざまな方がおっしゃっていたので、当てはまる方はぜひ導入を検討してみてください。

またこのようなイベントを取材したいという方を募集中です。僕一人はそろそろ限界ですやる気のある方はエンジニアライター募集から!

(この記事の反響が良ければAWSSummit大阪行けるかもなのでシェアしてください、お願いします)

SHARE

RELATED

  • お問い合わせ
  • お問い合わせ
  • お問い合わせ