[レポート] ARC347-アンドンコードの再発明: Amazon のバーチャル アンドン #reinvent

はじめに

ふかさわです。これはre:Invent 2019のセッション 『ARC347 - Reinventing the Andon Cord: Amazon Virtual Andon solution』の参加レポートです。

セッション概要

チョークトーク形式で行われました。

The Amazon Virtual Andon solution was built for Amazon fulfillment centers as an issue and notification system, and it is now publicly available as an AWS solution. In this session, we go behind the scenes of the creation of this solution and explain how we incorporated AWS IoT Core to monitor and connect to devices on the floor. We also discuss how we used IoT Rules Engine and Amazon SNS to send event notifications and AWS AppSync to perform complex queries and aggregations using GraphQL.

翻訳したもの

Amazon Virtual Andonソリューションは、問題および通知システムとしてAmazonフルフィルメントセンター向けに構築され、現在はAWSソリューションとして公開されています。このセッションでは、このソリューションの作成の舞台裏で、AWS IoT Coreを組み込み、フロア上のデバイスを監視および接続する方法について説明します。また、IoTルールエンジンとAmazon SNSを使用してイベント通知を送信し、AWS AppSyncでGraphQLを使用して複雑なクエリと集計を実行した方法についても説明します。

セッション内容

アンドンとはなにか？

• 日本の製造業で始まったもの
• 製造業と倉庫などで使われていた
• 品質チェックし、欠陥があれば通知して、ラインを止める
• 何が起こっているかを確認し、問題を修正する
• Aamzonの倉庫でも使われている

アンドンの代表的なフロー

• ステップ
  • 現場スタッフは問題を見つけてアンドンを有効にする
  • 有効にしたアンドンをフロアマネージャーが気づく
  • フロアマネージャーは調査のために「何が起こった？」と尋ねる
  • エンジニアは問題を解決するために呼び出される
• Amazonではタブレット、スマートウォッチ、PCで問題を確認できる

Amazonの倉庫でも使われている

• (Amazonの倉庫で実際に使われている動画)
• コンベアの途中で荷物が詰まる
• スタッフの持ってるタブレットに通知が来る
• スタッフはどこでどんな問題がおこってるかが表示される
• スタッフは現場に行って問題を解決する

設計方針

• Multiple factory setups
• Ease of use 簡単に使える / 何をする必要があるのかが分かる
• Ease of extensibility 簡単に拡張できる / 新しい機器に接続するなど
• Reactive vs proactive process リアクティブvsプロアクティブなプロセス
  • もっとプロアクティブなプロセスにしたい

設計

• アーキテクチャ、どのサービスを使うべきか、熟考した
  • Database / 多くのグループ、多くのエリアや拠点がある
    • Relational
    • Non-relational
    • graph
  • API
    • API Gateway / RESTful
    • AppSync / GraphQL
  • AWS IoT Core /
    • 使う？
  • Development Tools
    • AWS Amplifyなど
  • Distribution
    • CI/CDパイプラインなど

実際のアーキテクチャ

• Database: DynamoDB
• API: AppSync
• WebFront: CloudFront/S3
• 認証: Congnito
• 機器とAWSの接続: AWS IoT Core
• ロジック: Lambda
• 通知: SNS
• 見える化&プロセスの最適化: EMR/Elasticsearch Service/Kibana/Sagemaker

まとめ

Amazonの倉庫のシステムをお題にしたセッションで、特にIoT系のアーキテクチャ例や、設計するまでのAmazonのプロセスが分かりました。AWSの中でも同じことを達成するのに沢山の選択肢があります。明示的にユースケースから設計方針を明確にして、アーキテクチャに落とし込んでサービス選択を行うことで、できるだけ最適な解を見つけられるヒントになるでしょう。 今回のユースケースだとこのアーキテクチャを選択しましたが、違うユースケースだと、どんなアーキテクチャになるだろう？という議論ができれば、もっと面白くなりそうでした。