Pathee engineering blog

世界をしなやかに変えるエンジニアたちのブログ

AWS Summit Tokyo 2019 参加レポ【前編】

Patheeエンジニアの @mikan3rd です!

6月12日(水)〜14日(金)、幕張メッセで「AWS Summit Tokyo 2019」が開催されました

aws.amazon.com

自分はインフラ方面が苦手で、AWSに関する知見はほとんどありません。

しかし、プログラミングを始めたばかりの時にEC2をちょろっと使ったことがあり、AWSのサポートが親切だったことは覚えています。

当時は料金体系の仕組みがよく分かっておらず、練習で立てたインスタンスを放置してたら少し課金されてしまいました。

「どうしたら無料で運用できますか?」みたいなアホな問い合わせをしたにも関わらず、カスタマーサービスの担当者の方が親切に回答してくれた上、「お客様の意図しないものだったようなので今回限りですが返金させていただきます」と返金までしてくれました。

(ちなみにインスタンスを2台稼働させていたせいで無料枠の750時間を超えていただけです)

転職後はAWSに触れる機会がなかったのですが、PatheeでもAWSを本格的に使おうという機運が高まったこともあり、勉強がてら参加することにしました

f:id:pathee:20190614003127j:plain

会場の様子

自分は6月13日(木)の2日目に参加しました!

AWSともなるとスポンサー企業も錚々たる顔ぶれですね

f:id:pathee:20190614003146j:plain

会場はこんな感じで、スポンサー各社のブースもありましたが、連続でセッションを予約してしまっていたので行けませんでした😭

f:id:pathee:20190614003527j:plain

セッションによっては次のような広いスペースを4つに分けて並行して行っていました。

f:id:pathee:20190614003420j:plain

この場合、マイクを使うと隣のセッションの妨げになってしまうので、受講者はトランシーバーのようなものを使って自分のセッションのチャンネルを聞く、という画期的な取り組みが行われていました

f:id:pathee:20190614003222j:plain

イヤホンをしないと発表者の声は全く聞こえないので、何も知らない人が見たら壇上でスライドだけが流れていく異様な光景だったかもしれません

f:id:pathee:20190614003207j:plain

2日目の最後にはre:Mixというイベントが行われ、ビールやフライドポテトなどが振舞われる中で代表取締役社長の長崎忠雄氏から挨拶もありました。大企業の社長なので堅い感じなのかな?という偏見がありましたが、俳優にいそうなイケイケのおじさんでした

f:id:pathee:20190614003404j:plain

せっかく4つのセッションを受講したので、覚え書き程度ですが紹介させていただきます。

非インフラエンジニアでもできる!ビッグデータ分析基盤マイグレーション

スマホゲームビジネスにおいて、ユーザ行動分析とこれを支えるビッグデータ分析基盤はもはや必要不可欠である一方、設備投資と運用工数が莫大になりがちなこのデータ基盤をいかに合理化するかも極めて重要です。本来は高度なインフラ技術専門性を要求されるこの作業に対し、我々「非インフラエンジニア」が自社オンプレミスデータ基盤のAWSマイグレーションを通してどのように挑んだのかを、できる限り生々しく紹介いたします。

  • 株式会社セガゲームスのデータ分析基盤担当の方による発表
  • 上層部からのランニングコスト縮小の要請やオンプレでの設置場所からの退去指示などにより、10ヶ月でデータ分析基盤の移行を行うことになった時の話
  • 大手3社を中心としたパブリッククラウド選定に5ヶ月かけ、設計に登場したサービスは全て実際に試すようにしていた
  • AWSにした決め手はデータレイクとして非常に使い勝手が良いS3、何でも揃っているサービス群、豊富なオンラインドキュメント、ローコストなど
  • Simple Monthly Calculatorでコストの算出を詳細にすることができた
  • RedShiftとAthenaについて追加検証を実地したところ、軽量なクエリの場合はRedshift、重量のクエリの場合はAthenaの方が適していることが判明
  • 数百TBのデータ移行についてはSnowballという、送られてきたデバイスをつなぐだけでデータを抽出し、それをAmazonのデータセンターに送りつけるだけで移行作業をやってくれるというものを検討していた
  • AWSに移行後は年間のシステムコストを3分の1に、人員コストも3分の1にすることができ、障害の復旧も1日から数分程度まで改善することができた

テクロスにおけるAWS活用の歩み ソーシャルゲーム運用とデータレイクについて

株式会社テクロスでは、これまで、開発、運用しているソーシャルゲームにおいてAWSをフル活用してきました。 本講演の前半では、他クラウドからAWSへの移行から始まった、ソーシャルゲーム運用におけるAWS活用の取り組みについて、 後半では、AWS活用の内の一つである、Amazon Kinesis Data Firehose, AWS Glue, Amazon Athena等を利用した ソーシャルゲームデータレイク構築について事例を交えてご紹介します。

  • 神姫プロジェクトなどのソーシャルゲームの開発を行っている株式会社テクロスのエンジニアマネージャーの方による発表
  • 3年前まではAWS未使用で、インフラにおいては全てVMで構築し、ログの分析基盤もなくバラバラで管理している状態だった
  • 特に、当時利用していたVMが不安定なためどの占有ホストにどのVMを入れるかのパズルが発生していたり、メインデータベースに使用していたMySQL Clusterが原因不明で突然落ちるなど不安定で性能も悪いことが問題となっていた
  • 実際に神姫プロジェクトではリリース2ヶ月でMySQL Clusterが落ちてしまい、復旧しきれずに3日のメンテナンスを入れてロールバックを行う事件が発生したため、マネージドサービスへの移行を決意した
  • AWSを選んだ理由としては、最大手という安心感、VMの安定性が高い、Amazon Auroraのパフォーマンスが高い、問い合わせ後のサポート体制や契約までのスピード感が非常に良かった、など
  • これまでの反省を踏まえ、マネージドサービスを積極的に導入することで運用コストの削減を目指し、またVMを管理するミドルウェアが大幅に減ることにより構成管理ツールの見直しも行なった
  • 移行後はVMが全然落ちなくなり、たとえ落ちても自動復帰するのでインスタンスの安定度が格段に増した
  • また、Amazon Auroraなどマネージドサービス導入により運用コストが格段に下がり、APIを利用したインフラ構築の自動化みできるようになった
  • ただし、新しいリソースの追加が必要となった時に複数の環境それぞれに追加していくのが運用コストや、手動で行っていたため設定漏れなど事故の元になりやすいのが課題となった
  • そこで、冪等性を保った上で宣言的にインフラをコードで管理するツールとしてTerraformの導入を検討した
  • Terraformを本番環境で使うにはメンバー間の温度差などもあったが、毎週「Infrastructure as Code」の読書会の時間を確保し、半年かけて全員で読むことにより、概念の理解や達成したい理想の共有、現在運用中のサービスとのギャップの洗い出しを行った
  • この取り組みにより、チームにおける共通言語と共通認識を得ることができ、最も懸念を表明していたベテランが一番Terraformの導入に前向きになったのが非常に嬉しかった
  • 導入後は複数ある同環境への変更の適用が格段に楽になり、変更内容やタイミングの管理もしやすくなり、開発環境と本番環境の差異もなくなって事故要因を潰すことができた
  • ログについて、ソーサルゲーム運用にはユーザー行動ログ、APIアクセスログ、アプリケーションのエラーログ、課金やガチャ結果などのログ、スロークエリなどデータベースのログなど様々必要となるが、これはKPI分析やCS対応、不具合調査、不正アクセス検知などに欠かせないものである
  • それまではログの保存形式や保存箇所がバラバラで、DBクライアント+SQL、KIbana+クエリ、コンソール+シェルコマンドなど管理コストも学習コストも高かった
  • また、ログの量は1日あたり数百GBにもおよぶが、ElsaticSearchはログの単価が高いので長期保存には向かず、MySQLはテーブルにデータを溜めすぎるとパフォーマンスが落ちるなど辛いポイントが多々あった
  • 一方、S3はデータの保存単価が安く、Athenaはクエリ実行時のみ料金が発生する、分析用SQLが使えるなど便利
  • データレイクについてはRedashからAthenaに対して接続してSQLを発行するようにし、プランナーやマーケティングチームにクエリを描いてもらうことでKPI分析をスムーズにできるようになり、ダッシュボードで見える化もできた
  • 上記を踏まえ、新しいツールやサービスを積極的に検証・導入すること、その上でベストプラクティスを大事にすることが大事だと感じるようになった
  • また、移行後の負荷対策や不具合対応についてもAWS技術サポートやソリューションアーキテクトの方に非常に助けてもらい、AWSのサービスで一番良いのは何かと言われたらサポートと答えたい

Amazon SageMaker Deep Dive

Amazon SageMaker は 2017 年の AWS re:Invent で発表されて以来、お客様からのフィードバックによる機能追加とともに、多くの機械学習・深層学習ワークロードのプロダクション導入を進めてきました。本セッションでは、プロダクション環境で必要とされる継続的な機械学習ワークフローについて概観し具体的なアーキテクチャを例にとりながら、その中でも Amazon SageMaker にフォーカスします。Amazon SageMaker を使って、質の高いアノテーション、効率の良い分散学習、安定したデプロイを実現する方法についてお話しします。

  • AWSのソリューションアーキテクト担当の方からAmazon SageMakerの紹介
  • AWSは「全てのデベロッパーに機械学習を」目指している
  • 中でも「Amazon SageMaker」は機械学習モデルの構築、トレーニング、デプロイなど、機械学習のワークフロー全体をカバーする完全マネージド型サービス
  • 世界各国の企業はもちろん、Cookpad、dely、SmartNewsなど、日本でも機械学習の基盤として利用されている
  • レーニングデータの収集と準備については、Amazon SageMaker Ground Truthにより一般的なラベル付けタスク用の組み込みワークフローとインタフェースを提供しているだけでなく、自動ラベル付け機能を活用すれば、ラベル付けコストを最大で 70% 削減できる
  • 機械学習アルゴリズムの選択と最適化については、TensorFlow、Apache MXNet、PyTorch、Chainer、Scikit-learn、SparkML、Horovod、Keras、Gluon を自動的に構成して最適化することができる
  • Amazon SageMaker を本番稼働用環境に簡単にデプロイして、リアルタイムデータやバッチデータに対する推論の生成を開始できる

機械学習の実運用でよくある課題と, AWS を使った解決方法・事例紹介

AWS のお客様は Amazon SageMaker をはじめとした AWS サービスを組み合わせることで、様々な機械学習ワークロードを実際に稼働させています。本セッションでは、AWSを使った機械学習の導入や運用にあたりよく出てくる課題を踏まえ、それらを解決するAWS サービスとクラウドアーキテクチャについて、インターネットメディア、自動車、製造業など、様々な業界におけるお客様の事例を交えながらご紹介します。

  • 同じくAWSのソリューションアーキテクト担当の方からAmazon SageMakerの事例の紹介
  • SageMakerを使うことで、dely株式会社は「kurashiru」において1.5ヶ月で機械学習のサービスをリリースした
  • パーソナライズされたレシピを提案する機能で、これによりCTRが15%上昇した
  • ユーザー分類にK-Means、レコメンドfactorization machineを使用
  • SmartNewsでは記事の自動分類(カテゴライズ)にSageMakerを使用
  • また、ScientistとDeveloperで環境を統一することが容易となり、トレーニングデータ作成から本番稼働まで5日で実現できた
  • DeNAのAIを活用した交通事故削減サービス「Drive Chart」もSageMakerを使用
  • AI研究開発エンジニア・データサイエンティスト・MLエンジニア(API化・本番運用)が存在するが、コンウェイの法則にあるように組織にあった機械学習アーキテクチャーを実現できた
  • mixiファイトリーグでは、約2週間ごとに追加されるキャラクターに対し、SageMaker RLを使うことで分散学習環境を簡単に構築し、正常に動作するコンピューターを作成できた
  • AI創薬のSyntheticGestalt社では医薬候補となる低分子化合物の設計にSageMaker利用した機械学習を利用している

まとめ

前段の2つは自社インフラをAWSに移行した体験談でしたが、両者ともAWSの知見がない状態から大規模な移行を実現でき、移行後の満足度も非常に高いように感じました。特に「AWSのサービスで一番良いのは何かと言われたらサポート」という言葉は印象的で、冒頭で述べた自分の話に繋がる部分もあるので納得です。AWSは機能が多すぎるほどあるので自分のようなインフラ弱者には手を出しにくい感じがありましたが、SA(ソリューションアーキテクト)や技術サポートをうまく活用するのがベストプラクティスのようですね。

また、自分が未熟なだけかもしれませんが、AWS機械学習に強いというイメージはあまりなかったので、既に多くの企業でAmazon SagaMakerが実運用されていることを知ったのもためになりました。自分はAutoMLやCognitive Servicesのような各社が用意したモデルを使ってトレーニングや推論を行うぐらいしかやったことはないのですが、Sage Makerを使って機械学習の道にもう一歩進んでみたいですね。

通称「消化器」さんによる後編も是非読んでみてください

pathee.hatenablog.com

それでは、また次回!