まりぱらおーぐ

主にコンピューター周辺の話を中心に、気ままに書いていきます。

M5Stack GO を社内ハッカソンで活用してみた話 #M5Stack

f:id:o_chicchi:20191212004114p:plain

はじめに

こんにちは。@o_chicchi こと、おおぐちさとるです。

本記事は、M5Stack Advent Calendar 2019 の 2019/12/12(木)の記事です。 今回は、社内のハッカソンで、M5Stack GO を使った成果物の紹介をしたいと思います。

社内ハッカソン

弊社の勤務先では、親会社主催でグループ会社合同で、「テクのこ」というハッカソンを社内向けにやっています。 親会社は、株主さん向けにも、新卒募集のインターン活動の中でも紹介しています。

今回は、私も含めた4名のチームを事務局が編成したので、そこに参加してアイディア出し、開発を行いました。毎回、難しいのは、営業といった部署の人も参加するので、必ず技術スキル高い人たちばかりではないのは大変なところですが、スライド作成がそこまで得意ではない私にはありがたいです。

私は、過去にも参加していまして、その時の内容は、次の記事を参照してください。

blog.maripara.org

今回のアイディア概要

今回は、呑み会などのシーンにおいて、新人や海外からまだ来たばかりでチームに入ったばかりの人に配慮してあげたいということをテーマに、J!NSMEME を使って視線を取ってみようかと考えました。今回の話はそこがメインではないので、そこは詳細には触れません。

f:id:o_chicchi:20191212005627p:plain

f:id:o_chicchi:20191212005715p:plain

視線を頭の傾きに置き換えて、次のスライドの右側にあるイラストを出すデバイスとして、M5Stack GO を使っています。

f:id:o_chicchi:20191212010628p:plain

全体の構成

J!NSMEME から入ってきた値を処理して、M5Stack GO と、ラズパイに JSON でデータを送って処理する構成にしました。

M5Stack GO の UIFlow が、MQTTS 非対応のため MQTTS から MQTT の処理とする必要がありました。そのため、EC2に、mosquito を導入して、AWS IoT Core の後段に置きました。

f:id:o_chicchi:20191212010951p:plain

M5Stack GO の処理

M5Stack GO に期待する処理は、2つあります。JSON で入ってきたデータを処理して画像を表示することと、M5Stack GO をビアグラスに付けることにしたので、そのモーションを取ることです。

まずは、前者の処理から、JSON を受け取って、含まれている A の文字数をここでは数えています。なんでこんな処理にしたのかなぁ...とは思うのですが(笑) 初めてだったし、夜中だったしなぁ..ということで。

UIFlow 1.4.2 は、デコードの処理が増えているので、いろいろ試して直したいと思っています。

f:id:o_chicchi:20191212013535p:plain

画面については、リセットできるような仕組みを入れてあります。

f:id:o_chicchi:20191212014822p:plain

後者の処理ですが、ビアグラスの動きを取りたかったのですが、なかなか思ったような動きにならず、苦戦しました。今後も研究の余地はありそうです。

JSON の生成も簡単には書けず、文字列を生成して突っ込んでいます。Python ならもっと簡単なのにと思ったのはヒミツです。

f:id:o_chicchi:20191212015613p:plain

開発した感想と周辺の反応

UIFlow に関しては、MicroPython に変わるタイプのようなこの手のツールはないので、面白いとチームメンバーも思ってくれたようです。

でもですね、回りにアドバイスもらえる人が居ないのが、いちばん大変でした...(笑)

おわりに

UIFlow 初チャレンジだったのですが、もっと勉強します...。

宣伝

12月14日の技術書博覧会で、Swift&Kotlin愛好会で、Raspberry Pi で、Swift を使う話を寄稿しました。 まったくもって、また関係ない話を(笑)

よかったら、手に取ってください。

SORACOM UG explorer 2019 で、LT をしてきた話 #SORACOM #SORACOMUG

f:id:o_chicchi:20191209230303p:plain

はじめに

こんにちは。@o_chicchi こと、おおぐちさとるです。

本記事は、SORACOM Advent Calendar 2019 の 12月10日(火)の記事です。昨日の SORACOM explorer 2019 のスタッフの木澤さんからの記事を受けて、翌日とは、なかなかのプレッシャーであります。

内容ですが、先日の SORACOM UG explorer 2019 で、LTさせていただいた内容の紹介と、その裏話、盛り込めなかった内容について解説します。

LT資料

登壇資料を以下にアップロードしました。天気の子とパトレイバーは見逃して下さいw

SORACOM UG explorer 2019

f:id:o_chicchi:20191209230434p:plain

先に、SORACOM UG explorer 2019 の話を。

私は、このアドベントカレンダーの昨日の記事を書かれた木澤さんからの強いお誘いもあって、LTも含めて参加させていただきました。

今回の最大の収穫は、SORACOM 玉川社長の人柄が会社にとても出ているということを知れたことかもしれません。 懇親会のビールを自ら配って回るとか、政治家になるべきだというネタに対して、ちゃんと返してくれるところとか、この人あっての会社だなと。

あんまり言いたくないですが...弊社と違いすぎます(苦笑)

SORACOM UG explorer 2019 のスタッフの皆様、登壇者の皆様、SORACOM社員の皆様、お疲れさまでした。おかげさまで楽しく過ごさせていただきました。

気圧測定の話

台風19号の時に気圧を測った話をさせていただきました。M5Stack に、3Gボードを付けて測定をしました。 既にお気づきかと思いますが、台風の時は、外出なんてできないので、3Gボードを使う必然性が、ここには全くありません(笑) Wi-Fi でいいのです。

f:id:o_chicchi:20191210010855p:plain

ただ、以前、デモ用に作成した環境がありまして、それを使いたかったのです。ちなみに、Amazon Connect を使って値を電話で聞けるようになっています。 Youtube に、当時、作成したデモ動画があるので、是非みてみてください。

この時の環境は、WioLTE と、M5Stack の両方が選べるようになっています。ただ、WioLTEは、別のテストに使いたかったので、現在は、改造されていて、M5Stack のデータしか聞けません。

www.youtube.com

ただ、測定して出てきた結果はとても興味深かったです。他の低気圧とか台風でも測ったことがあるのですが、961ヘクトパスカルという極めて低い値になった記憶ないですね。私は半分、値を見ながら気持ち悪くて寝てました。

f:id:o_chicchi:20191209215244p:plain

時刻表示の話

データ測定している中で、こんなアラートが飛んできているという話をしました。

f:id:o_chicchi:20191209215701p:plain

これは、この時だけでなく、以前から気になっていました。WioLTE では、時刻を簡単にとることができたので、10分に1回の測定データを送る仕様に変えていたのですが、M5Stack は、この 3G モデムを使った場合、いろいろ試行錯誤していたのですが、時刻が標準の仕組みでは取れなかったんですよね。

なんとなく理由は分かっているのですが、細かいところまでは解析できてないので、うまくは説明できないです(苦笑)

ただ、3G(UMTS)モデムである以上は、携帯電話網に時刻の情報があるということになっています。なので、網から取りたいなと思ったのが、もともとのきっかけです。 なので、TinyGSM のライブラリのリポジトリを見ていて、他のモデムのソースコードを眺めていてコメントに気づきました。

// This is only supported on SIMxxx series
// String gsmLoc = modem.getGsmLocation();
// DBG("GSM location:", gsmLoc);

// This is only supported on SIMxxx series
// String gsmTime = modem.getGSMDateTime(DATE_TIME);
// DBG("GSM Time:", gsmTime);
// String gsmDate = modem.getGSMDateTime(DATE_DATE);
// DBG("GSM Date:", gsmDate);

なので、ATコマンドを直接叩けないか調べていて、サンプルコードに、AT_Debug があることに気づいたので、これでいろいろ調べてみました。

f:id:o_chicchi:20191209223144p:plain

LTでは省略していますが、改造点について解説すると、#include に以下を追加すること、

#include <driver/dac.h>
#include <M5Stack.h>

あと、Serial が被っているので以下のようにします。

// Set serial for debug console (to the Serial Monitor, speed 115200)
#define SerialMon Serial

// Set serial for AT commands (to the module)
// Use Hardware Serial on Mega, Leonardo, Micro
#define SerialAT Serial2

このくらいで使えると思います。

実は、資料上では、ATコマンド、4つくらいしか取り上げていませんが、他にもいろいろ叩いてみています。データシート見て叩くと面白いです。

f:id:o_chicchi:20191210005014p:plain

ソースコードの改造ですが、TinyGSMのライブラリのsrcのディレクトリにある TinyGsmClientUBLOX.h を書き換えています。 以下の部分を、496行目あたりに追加しています。

  /*
   * Time functions
   */

  String getGSMDateTime(TinyGSMDateTimeFormat format) {
    sendAT(GF("+CCLK?"));
    if (waitResponse(2000L, GF(GSM_NL "+CCLK: \"")) != 1) {
      return "";
    }

    String res;

    switch(format) {
      case DATE_FULL:
        res = stream.readStringUntil('"');
      break;
      case DATE_TIME:
        streamSkipUntil(',');
        res = stream.readStringUntil('+');
      break;
      case DATE_DATE:
        res = stream.readStringUntil(',');
      break;
    }
    return res;
  }

こうすることで、以下のようにすると日付、時刻がとれるようになります。

String gsmDate = modem.getGSMDateTime(DATE_DATE);
String gsmTime = modem.getGSMDateTime(DATE_TIME);

私のプログラムの中では、TimeLib.h を使って内部の時計を補正して使っています。 そのようにすると、以下のような表示ができる状況になりました。

f:id:o_chicchi:20191209225443p:plain

最後に

重ね重ねですが、登壇する機会をいただけたことに感謝申し上げます。 最近、違うことにも取り組んでいたりするので、またアウトプットできたらと思います。

それから、いつも一緒に遊んでくれる皆さんにも感謝です。ここ、2〜3年くらいの僕にとってのネットワークの広がり方は大きくて、今まで何やっていたんだろうというくらいのスピードです。

また、本記事を見て、#SORACOM や、M5Stack に少しでも興味持ってくれたら幸いです。

明日は、 IoTLT vol.56 @SCSK、SORACOM UG explorer 2019 での LT の MVP とも言える 樋口さんの「モテモテスイッチの作り方」です。 これを作ると、あなたもモテるようになりますよ!!

(樋口くん、がんばれー)

JAWS-UG IoT専門支部 「AWS IoTシリーズのシンカ(進化/深化/真価)」を運営してきました #jawsug_iot #jawsug

はじめに

以下のイベントを、ioT 専門支部のメンバーと運営してきました。1年ぶりです。すみません。

jawsug-iot.connpass.com

AWS IoT サービスこの1年の進化 AWSJ 亀田さん

f:id:o_chicchi:20190820193602p:plain

AWS IoT サービスのここ1年の進化について話をしてもらいました。印象だったトピック。ちなみに、受付やっていたので話は途中から。

  • AWS IoT Core と Kinesis との比較。課金上は、AWS IoT の方が高い。

  • AWS IoT Device Defender の機能説明

  • Amazon FreeRTOS

    • FreeRTOS は買収したというより、開発者が、AWS に入社して開発を継続している。
  • AWS IoT Greengrass

    • Linux kernel > 4.4
  • AWS IoT Greengrass ML Inference

    • Amazon SageMaker neo を利用することで推論の高速化ができる。
  • AWS IoT Analytics

    • IoT Core のデータを保存して、解析する機能
    • Kinesis Firehoseの代わりに使われるようになってきている。
  • AWS IoT SiteWise

    • クラウドにデータを一度アップロードする。
    • SiteWise Gateway は、住所を登録する必要があるが、必ず使う住所で。違うところで登録してバレると面倒とのこと。
  • AWS IoT Core ハンズオン

    • 2019/09/13 @ Loft 18:30〜
    • これからハンズオンテキストを作るらしい。

AWS IoTサービスの理解の深化と真価(仮) AWSJ 市川さん

f:id:o_chicchi:20190820200958p:plain

AWS IoT Events と、AWS IoT Things Graph についての説明。印象的だったこと。

  • AWS IoT の歴史

  • 現在の分類

    • Device Sofrware
    • Control Services
    • Data Services
  • 今日の説明

    • AWS IoT Things Graph
    • AWS IoT Events
  • AWS IoT Events

    • ステート管理が可能
    • Build, Monitor, Automate
    • 生産設備に実装して、予防保守に活用する。
    • 電動キックボードをレンタルするサービスで、位置情報が変わり続けるものを検出したりすることができたりする。
    • デモ
      • IoT Events のコンソールを実際に使いながら説明。これは、Lambda 書かなくても出来る事例増えるのかな。
    • Action が様々に指定可能。
    • 注意点
      • 編集中のモデルは保存されない....つらい pulish しないといけない。
      • 一定期間がデータがこないと保存されていないデータとモデルが削除される。30日前に予告ある。
    • モデルのダンプが CLI で可能。
    • IoT Core の Rule より複雑な条件が指定可能
    • AWS IoT Core と、AWS IoT Analytics からデータが受け取れる。
  • AWS IoT Things Graph

    • 自動化フローを大規模に作成して運用負荷を減らすことができる。
    • Node-RED っぽい。
    • 独自のモデルの勉強が必要。
  • デモ

    • デバイス定義の GraphQL の定義がちょっと理解が大変。でもこれが増えると使いやすいかも。
  • IoT アプリケーションを素早く作成できる

  • AWS INNOVATE がありますよ。

  • Getting Started はこのあたり?

docs.aws.amazon.com

docs.aws.amazon.com

IoT のつくりかた IoT専門支部 青木さん

f:id:o_chicchi:20190820205037p:plain

ハードウェアの話を主に話をしてくれました。

  • 電源問題。コンセント自体使えなくなる! お客様のレイアウト変更でセンサーにアクセスできなくなる!

  • 補正できるデータとできないデータがある

    • イベントデータは永遠に取得できないので、再送などの実装を考えることは必要である。
  • エリアネットワークのプロトコル問題

    • WiFI は、待ち時間を短くして再送する。
    • XBee は、5回再送すると捨てられる。
    • 周波数が被っているので注意が必要。
    • 無線問題は大きい。
  • デバイスのスペック

    • 選定する時に使う機能から選定するようにしたほうがよい。
  • 広域通信網

    • 3G はリプレースが見えている。
    • LPWA を使う
  • とあるお客様の案件でアクセス要件が厳しいので、SORACOM Napter を利用して、IoT Gateway をメンテナンスするような仕組みを用いた。

まとめ

  • Twitter のまとめ

togetter.com

  • 私も同意見です。

  • 個人的感想
    • AWS IoT Analytics と、AWS IoT Events は、やっぱり知識として深めておきたい。
    • Kinesis を理解したくて触っているこの頃なのですが、やっぱりよくわかってない。

懇親会

  • 写真撮るのを忘れました。

  • 普通に面白かったです。

メモ: Amazon Kinesis DataStreams のストリームの作成

はじめに

Amazon Kinesis DataStreams のストリームの作成方法をメモ

やりかた

「いますぐ始める」を選択する。

f:id:o_chicchi:20190813160443p:plain

4つから選べるみたい。今回は、データストリームを選択する。

f:id:o_chicchi:20190813160619p:plain

ストリーム名を、sample と指定する。

f:id:o_chicchi:20190813160931p:plain

同じ画面で初期シャード数は、1としてみる。

f:id:o_chicchi:20190813160956p:plain

Kinesis ストリームの作成を選択する。

f:id:o_chicchi:20190813161023p:plain

できあがりを確認する。

f:id:o_chicchi:20190813161202p:plain

CLI

$ aws kinesis create-stream --stream-name sample --shard-count 1

参考

AWS 西谷さんの書籍から。

社内ハッカソン「テクのこ」に参加してきました

社内のハッカソンに参加してきました

最近、ハッカソンが流行っていますよね。最近でもないか...。

弊社の勤務先でもグループ会社合同で、ハッカソンを社内向けにやっています。 親会社は、株主さん向けにも、新卒募集のインターン活動の中でも紹介しています。

先日、私も参加してきました。せっかくなので、記録に残しておきます。

開催日時と場所

ハッカソン

2017年10月27日(金)〜28日(土) @SCSK多摩事業所

今回は、初めて、インターン生との共催ということになりました。 インターン生は、夜中開発はできないというお約束があります。

社内発表会

2017年12月1日(金) @SCSK豊洲本社

社内向けの発表会です。一応勤務時間内ですが、許可を貰った上で行っています。

グループ編成

グループは他で開催されるハッカソンと違い、編成は開催する事務局がします。

背景としては、会社の規模や、事業内容の背景もあり、開発経験がない、あるいは、浅いという人も多いです。 開発だけでなく、営業部門、サポート部門があったりしてこそ、サービスが成り立つので、会社全体でみると開発者ばかりにはならないのは、自然なことだと思います。

そのため、開発経験者や経験を考慮したチーム編成がされます。 なので、私と性質が近い人がもちろんいる訳ですが、絶対一緒にならないだろうなぁ...という人もいます(笑)

年齢も様々で、入社1年目もいれば、もうすぐ定年という人もいます。 いろいろな人の考え方、やり方を学べるので、このチーム編成のやり方、面白いです。

勤務時間外の活動

先ほどの日程のうち、金曜日は、有給休暇の使用を前提としています。

メリットとしては、ここでの制作物の権利は、会社に帰属せず、作成者に帰属することになっています。 なので、こうやってブログに書いても、守秘義務項目にあたらないので問題はありません。

また、一方で、遠方からの参加者であっても、交通費が支給されます。ただ、労災対象外なので、別途、保険をかけてくれています。 社内とはいえ、研修センターを借りて宿泊費も負担してくれています。

なので、コストはけっこうかかっているとは思います。 こういうのにお金を出して頂けることは有り難いですね。

社内の人、全てに理解されているとは思いませんが、比較的理解のある人は多いなと。

自分の上司は、好きにしていいとのことなので、好きにしています(笑)基本的には反対はされません。 こいつは、言ってもきかないから、仕方ないなーときっと思われてます(笑)

支給品

希望者には、レンタルのパソコンが、1台、あと、Raspberry Pi、マイク、カメラとか、AR/VR デバイスなど、様々なものを借りることが出来ます。 持ち込みも自由です。

私は、My Mac を持ち込んみました。必要な開発ツールが入っているので。 Raspberry Pi は、セットアップ済みのものが提供される訳ではないので、セットアップ済みのものを用意していきました。

また、使用はしませんでしたが、Google Home Mini も持参しました。 事務局で用意するリストになかったので、持参したら、Google Home ありました(笑)

主なタイムスケジュール

1日目

  • 午前 チームビルディング/アイディアの決定
  • 昼食
  • 午後 開発(環境作り〜開発)
  • 夕食
  • 夜間 開発(開発〜テスト)

2日目

  • 朝食
  • 午前 デバッグ/プレゼン準備
  • 昼食
  • 午後 発表会、審査
  • 後片付け
  • 夕方 結果発表〜パーティ

作ったもの

Google Home on the kitchen というテーマにで、キッチンで料理動画をみているときに、その動画の再生や停止ができるというものです。すごくシンプルに作ることを考えたので、開発のボリュームはそこまで大きくありません。

デモ動画


Google Home on the kitchen

技術背景

システム構成図を以下に示します。開発の難易度を下げるために、IFTTT と、使い慣れた AWS 環境を利用しています。

f:id:o_chicchi:20171228155231p:plain

苦労した点

開催されたのが、Google Home の日本発売の直後で、私も入手したのが、1週間程度前という状況だったので、IFTTTや、Actions でどういう形で連携が可能か、調査から行いました。

Google Home を使ったことのある人なら、反応の精度の良さについては、驚かされたと思うのですが、予約語で使われているものが多く(「再生」とか)、ひたすら試して使えそうな言葉、話し方の工夫をして、思う出力を得ることに注力しました。

人間とは面白いもので、認識されると分かると話し方が早くなったりするようで、ある時点から認識されないと悩んでみたりします。 少しゆっくり丁寧に話すと認識しやすくなるようです。

あとは、WebSocket の部分ですね。私は、仕組みは知ってましたが、プログラムの書き方は、今回、初めて知りました。 とても勉強になりました。いろいろなパターンでコード書いて、モノにしておきたいです。

また、nodejs の有識者がチームにいなかったので、構成が少し冗長な構成となっています。

発表会

発表会に向けて工夫した点は、シナリオを固定したことです。

前項にも書いていますが、音声認識の問題もあるので、全体的なデモシナリオを固定することで確実なデモができるようにしました。

デモは、私が考えたものではないのですが、よいデモができたのではないかと思っています。

結果

結果は、審査員の審査により、優勝でした。別途、テクのこ賞という高専ロボコンのように、優勝しても、実際の優秀賞は別にあるみたいなところがあるので、実質、2位というのが実情でしょうか。

良い結果をいただけたことにチームメンバーの皆様に感謝しています。審査員コメントに、Google Home に頼りすぎとも言われましたが(笑)

f:id:o_chicchi:20171228155831j:plain

その後

発表会が終わった翌日、チームメンバーから思い出だからといって、Google Home 購入者が発生し、同じハッカソンに参加した人たちにも、気に入って、続々買うという面白いことが発生しました。会社の同僚にもデモ見せたので、Google Home といったスマートスピーカーが、私の周辺で広まっています。

私は、最近、Amazon Echo も購入しました。 プログラムを全体的に見直して、Echo対応も試してみたいと思っています。

AWS Solution Days 2017

f:id:o_chicchi:20170705213304p:plain

AWS Solution Days 2017 ~ AWS DB Day ~

有給休暇を取得して、あくまで個人として、AWS DB Day 2017 を眺めてきました。 参加したセッションを中心に少しだけメモを公開。

現在の担当のお客様は、AWS使ってくれないので、無縁なので会社に申告しにくかったし、専門分野は一応違うので。

いずれ、ビデオとかスライドは公開されるのではないかと。

基調講演

基調講演は、途中から聞いてました。自分もそうですが、基幹システムの標準は、今でも、Oracle が標準だったり、自分の仕事の中での悩みは一緒だなと思って聞いてました。

公演内容は、公式サイトより。

  • Amazon Aurora for PostgreSQL Compatibility を評価して

    • 石井達夫さん(SRA OSS Inc.日本支社 取締役支社長)
  • 100コア時代に通用するデータベースソフトとは?本当のスケールアウトとは?

    • 小幡一郎さん(株式会社インサイトテクノロジー 代表取締役社長)
  • シェアードナッシング型 Web アプリケーションと Kinesis Firehose による大規模データストリーム処理

    • 倉林修一さん(株式会社Cygames 技術顧問 兼 サイゲームスリサーチ所長)
  • 感想

    • 倉林さん(Cygames)の話は、システム構成としても定石としては、やりかたはわからなくもないですが、大学の先生もされているとかで、話もよかったですし、説得力抜群でした。

クラウド上のデータ活用デザインパターン

  • 登壇者

    • 志村誠さん(AWS JAPAN SA)
  • データ活用の流れ

    • データを貯める
    • データを可視化
    • データサイエンス
  • If Your Company Isn’t Good at Analytics, It’s Not Ready for AI.

hbr.org

  • データ活用は試行錯誤が必要

  • オンプレミスの問題

    • 時間の柔軟性
    • アーキテクチャの柔軟性
    • リソースの柔軟性
    • ワークロードの柔軟性
  • AWSデータ活用環境

    • データレイク
      • S3 にデータを蓄積してその周辺にサービスを展開する考え方
    • 全てのデータを1箇所に集約する
    • データストアとデータ処理の分離
    • 用途に応じた適切な処理方法の選択
  • 関連するAWSのサービス

    • Amazon Redshift
    • Amazon Redshift Spectrum
    • Amazon EMR
    • Amazon Athena
    • Amazon Kinesis Streams
    • Amazon Kinesis Firehose
    • Amazon Kinesis Analytics
    • p2インスタンス & Deep Learning AMI
  • デザインパターン

    • パイプライン
    • 複数レイヤの分析
    • ホットデーター
    • ラムダアーキテクチャ
    • 分析
  • 感想

    • Summitでも、志村さんのセッションは聞かせていただいていて、内容はとても有益でありがたいのですが、僕は、彼の話のスピードに必死についていくしかなく、終わるとどっと疲れるのは内緒。特に、If Your Company Isn’t Good at Analytics, It’s Not Ready for AI. は、素晴らしい引用です。
    • デザインパターンは、メモしきれなかったので、スライド公開に期待です。

ETL をサーバーレスで実現する新サービス AWS Glue のご紹介

  • 登壇者

    • 下佐粉 昭(しもさこあきら)さん(AWS JAPAN SA)
  • キーワード

    • スケールアウト
  • ETL処理

    • データの前さばき(フォーマット変換など)は必要
  • AWS Glue

    • 巨大データへのETLをスケールアウトで、サーバレスで
    • 内部では、Spark を利用している
    • スケールアウトは勝手にやる
    • PySparkで、ETL処理をカスタマイズ
  • AWS Glue の機能

    • データソースをクロールする
    • データカタログで管理
    • ジョブを作成する
    • サーバレスで実行される
  • データカタログ

    • 表のメタデータをHIveメタストアで管理
    • クロールする範囲を設定できる
  • ジョブオーサリング

    • データソースとターゲットを指定して、ETLジョブを定義
  • オーケストレーション

    • ETLスクリプトを読み込んで実行
      • IAMロールを指定できる
    • ジョブ実行
      • ジョブのスケジュール、先行ジョブ指定可能
        • 但しカレンダー機能なない
      • API 呼び出し
  • まとめ

    • サーバレスETL
    • Sparkベース
    • PySpark
    • プレビュー中
  • 感想

    • プレビュー申し込んでいじってみよう

オンプレミスから RDS for Oracle / SQL Server への Lift & Shift

  • 登壇者

    • 北川 剛(AWS JAPAN 事業開発マネージャー)
  • キーワード

    • クラウドファースト
  • データベースの課題

    • データ容量増大
    • システム連携
    • データ再利用
  • 検討するきっかけ

    • サポート切れ
    • システム更新
    • 拡張性の確保
    • コスト削減
  • 移行方法

    • Heterogeneous or Homogeneous
    • EC2 or RDS
  • Data Migration Service

  • 感想

    • まぁ、そうなんだよね。自分、社内システムの担当者じゃないからわからないことたくさん。

Big Data JAWS

Gunosy での Kinesis Analyticsの利用について

  • 登壇者

    • 小出幸典(こいでゆきのり)さん(株式会社Gunosy 開発本部 開発・運用推進部部長)
  • ストリーム、バッチ処理をする理由

    • サービス制約
      • ニュースは鮮度の制約がある
      • 見せられる量には制限がある - コンテンツへの反映
      • クリックされた情報などを即座に反映したい
  • Kinesis Analytics

    • ログを fluentd で転送
    • Kinesis Firehose -> Kinesis Analtics -> Kinesis FireHose -> Elastic Search Service
    • サービスが東京にないので、オレゴン使っている
  • Tips

    • 東京からオレゴンに転送するにはどうしたら良いか
      • Lambda はスループットは厳しい、汎用性がない
      • fluentd を導入した
  • 所感

    • 開発がラク、IAMは面倒
    • クエリだけ考えればよい
    • 運用はラク
    • Streams/Firebase の流量は注意(キャパシティ)
    • コスト削減できた
  • ブログ

data.gunosy.io

tech.gunosy.io

リクルートテクノロジーズにおける EMR の活用とコスト圧縮方法

  • 登壇者

    • 渡部徹太郎さん(株式会社リクルートテクノロジーズ ITソリューション統括部 ビッグデータ部、BigData JAWS 代表)
  • リクルートのビジネスモデル

    • リボンモデル
      • マッチングサービス、マッチングしてフィーをもらう
  • データ処理技術

    • 行指向
    • 列指向
  • Hadoop

    • Spark は、Hadoop でも動く
    • Hadoop は、プロジェクト名
  • Hadoop の特徴

    • データはファイル
    • 計算と分散ファイル配置は分離
  • EMRの特徴

    • Apache Hadoop をラッピングしたサービス
    • S3 に置けば移動しなくてもよい
    • クラスタは捨てられる
  • 利用方法

    • WebUIコネクタ
      • ELB を使って、処理画面を見せる
    • Hiveクエリを呼び出せるツールを作っている
    • スケジューラー
      • 起動したままだとコストは高い
      • 時間起動でインスタンスを選んで起動
        • 10分毎にチェックをしていて、不足したら、スポットで確保する
        • SpotFleetは今更です
  • 活用事例

    • EMR に移行で、サーバをタイムリーに増やせるので、開発や運用時にカバーできる
  • 感想

    • リクルートの分析基盤は興味深かったです。自前で、利用者の為のインターフェース作っているとか凄いですね。

ドコモビッグデータ分析基盤の AWS 上構築経緯と開発裏話

  • 登壇者

    • 佐々木純さん(株式会社NTTドコモ サービスイノベーション部 主査)
  • 分析基盤の特徴

    • 多種データ
    • 超大容量DB
    • 多数ユーザ
    • 少人数開発/運用
  • 苦労した点

    • 社内調整
      • 社内中のデータをクラウドに放り込むは、セキュリティリスクをしつこかった。
      • 別システム(コンシェル)の利用実績あり
    • 初めてのAWS
      • コンサル、AWSJのサポート
  • セキュリティ対策

    • 280 の社内基準
    • 運用者による内部犯行の防止
      • 単独でできない仕組みは必要
    • 閲覧情報の制限
    • データの持ち出しの制限
    • 運用グループA/B を作って、片方だけで作業を完結しないようにしている
    • 承認されたスキーマーされたものしかみえない
    • 多数のシステムカタログテーブルの権限を剥奪して、参照用のクエリを用意している
    • (昔のRedshiftでは)任意のバケットのLOAD/UNLOADができる問題があった
  • 問題

    • スキーマ数/テーブル数 枯渇問題
    • 不適切クエリの増加
    • CTAS問題
    • UDF問題(VOLATILEで全部やっていた)
  • AWSのアップデート

    • LOAD/UNLOCAD Revoke
    • インスタンス性能向上
    • VPCエンドポイント for S3
    • Redshift - S3 VPC エンドポイント対応
    • CTASの自動圧縮
    • Schema数の拡大
    • Redshift Spectrum
  • AWSへの要望

    • PostGIS
    • 最大テーブル数
  • まとめ

    • AWSに構築した。
    • セキュリティ
    • 拡張性
  • 感想

    • データセンター設置する場所探しからは、自分は経験ないので、水道工事するとか分からなかったですw
    • ラック立てて、ラッキングしたり、自分でパッチパネル付けたりとかの経験はありますが、さすが、ドコモw

全体的な感想

BigData JAWS の話はよかったですね。どっちかというと、Big Data的な話聞くのと、Aurora セッションが面白かったのかな。 自分でも、聞いた話をもとにいろいろ試してみたい。 (てか、AWS の勉強にさける時間あるの? 割かなきゃいけないんだけど...。)

印象的だったのは、AWS志村さんのお話の中の If Your Company Isn’t Good at Analytics, It’s Not Ready for AI. の引用ですね。データの分析すらできてないところは、AIとか言えないよ、とは、その通りです。

渡部さん(リクルートテクノロジーズ)や、佐々木さん(ドコモ)のお話にある分析基盤を作れないような会社は、時代にとりのこされるんだなと。

Developer.IO に参加してきました

f:id:o_chicchi:20170701213619p:plain

Developers.IO

2017年7月1日(土)のクラスメソッド社主催の Developer.IO に参加してきました。

開催場所が、SAPジャパン本社の半蔵門オフィスということもあり、興味もったのが最大の理由です。 たぶん、3Fと最上階使うのかなーとか思いながら。

本職が、SAPテクニカルコンサルタントなもので、SAPジャパン社のオフィスはたまに伺いますし、現在も、SAPジャパンの方と一緒にお仕事させてただいている(毎日メールやりとりさせていただいています...)ので、縁を感じたのもあります。

レポートは、後日サイトに載るそうです。

dev.classmethod.jp

この記事では、自分の参加したところの話と興味深かった部分のみです。ちなみに、個人的都合で、午前中は参加できず。Keynote聞きたかったです。

dev.classmethod.jp

このツイートなんか気に入りました。

基礎からのOAuth2.0〜認証と認可の概念、認可コードとアクセストークンの意味〜

メモそっちのけで聞いていましたが...目が悪くて見えなかったという噂も(笑)

このスライドと、RFC6749あたりを以下を見ながら整理したいです。

qiita.com

AWS Security Best Practices Whitepapaer をガッツリ読み解く会

AWS事業部のソリューションアーキテクトの森永さんがお話してくださいました。7/3(月)に第2子を授かる予定とのことで、拍手から始まりました。無事、生まれてくること、母子ともに健康であることを祈っております。

そのプライベートが忙しいさなかにやってくださった、このセッションがとても興味深かったです。最近、社内やお客様のAWS環境を考える上で、特にセキュリティの考え方を整理するべきと感じていたので、タイムリーでした。

参考は、以下のホワイトペーパー。

https://aws.amazon.com/jp/whitepapers/aws-security-best-practices/

日本語版もあります。以下のリンクから。

aws.amazon.com

https://d0.awsstatic.com/International/ja_JP/Whitepapers/AWS_Security_Best_Practices.pdf

AWS のセキュリティといえば、責任共有モデル、認定資格にも出てくる話です。最近は、よりPaaS的、SaaS的なサービスも増えていますから、モデルとして保証する範囲は当然違ってきます。ここは自分でも押さえていた部分です。

aws.amazon.com

ISMS というキーワードも出てきていたので改めて確認。機密性、完全性、可用性というキーワードは重要ですね。IPAの資格試験でいつも聞かれる部分ですし、お客様の要件決定する上でも気にする部分です。

ISMS(情報セキュリティマネジメントシステム)とは - 情報マネジメントシステム認定センター(ISMS-AC)

あとは、IAM の話が出てきました。IAM は、私は、AWS のサービスの中でも重要なところと位置づけていて、自分で環境を作成して、試したことの多い部分でした。ここは、悩み所で、緩くすると開発に支障が出る、厳しくすると、開発のスピード感が落ちる、これは、AWS に限らずよくある話です。

若干お話でましたが、自分の中では、開発、検証と本番は少なくともアカウントを分けるのが良いと思っています。

権限は、アクセスアドバイザーを使って洗い出すというのは認識ありましたが、マネージドポリシーに寄せておいて、やらせたくないものだけ、カスタムポリシーを使うという考え方で整理すると運用負荷が下げられるのではないかという点は、なるほどと思いました。 (よく考えれば、SAPの権限管理でも、私は、そう設計すること多いですね。)

IAM グループを活用するのもそうですね。管理負荷を落とすは重要だと思います。

それと、キーストレージの話もありました。ちょっと気になったポイントは、鍵の管理。確かに、鍵ペアを手元で作成してから、キーストレージに登録する方がセキュアですね。

aws.amazon.com

これは、私知らなかったんですが、MFA で削除の保護とかできるんですね。

dev.classmethod.jp

RDS の暗号化では、CSE暗号化 部分一致検索できなくなるというデメリットがある話。

他、ホワイトペーパー上では、廃棄する前に暗号化しで、キーを廃棄することでデータ廃棄時の安全性を確保との記述があるとの情報は、自分でも確認しようと思います。データ廃棄に関するプロセスは、以外と重要ですので。

EC2 System Manager の話でましたね。このサービス、私、導入したいです。

AWS Systems Manager(運用時の洞察を改善し、実行)| AWS

VPCのセキュリティ

docs.aws.amazon.com

VPCフローログの有効化もしたほうが良いでしょう。

docs.aws.amazon.com

だれもが悩むセキュリティグループ(SG)と、ネットワークACL(NACL)の話。基本は、SGで管理し、NACLは、攻撃者のIPをはじく、絶対使わないポートを閉じるとかで活用するのは、いい解ではないかと思いました。

docs.aws.amazon.com

スライド公開お待ちしています:-)

Amazon Elasticsearch Service の使いドコロ

今回、聞きたかった話の一つ。何にも知識がなかったので、とても参考になりました&参考にします。

dev.classmethod.jp

感想

このイベント3年目だそうで、個人的には、エンジニア向けだけでなく、カスタマーに向けてもやっていいのではと思いました。 話を聞いているうちに、自分も、もっとクラウドエンジニアの仕事やりたいなーと思ったのは秘密。

アソシエイトだけど、AWSソリューションアーキテクトの認定も取得できたし、SAPテクニカルコンサルタントの仕事、少々?、飽きているので(苦笑)

SAP on Cloud についてなんとなく

f:id:o_chicchi:20170612072953j:plain

はじめに

私は、メインの仕事は、SAP のいわゆる Basis と呼ばれるBtoBの業務基盤系の仕事してます。たいして、最近、この仕事、好きではないところが悩みなんですが。

また、主に、Basis ってだけで、開発とかAWSの基盤設計、設定みたいなこととか、他のことも多数やります。こっちの方が楽しいですね。それは、SAPのサ(以下、これ以上書くと暴言になるので割愛)

その仕事の中で、最近のクラウド環境に載せる SAP について、数日前に社内向けに資料作って、ニュースリリースとか調べたのでブログにもまとめておきます。特に、非公開な話でもないので。

ちなみに、資料作成自体も勤務時間にやっていません。様々な事情で自主活動なので。

各クラウドサービスの状況

各クラウドサービスの最近の状況のうち、SAP的(エンタープライズサービス的)に重要そうなところをそれぞれまとめてみます。 SAP HANA Enterprise Cloud の話は、ここでは触れません。パブリッククラウドのみです。

Amazon Web Services

あと、SAP on AWS のイベントを AWSの目黒オフィスでやるみたいですね。このあたりは、AWSのイベントページを確認するとよさそうです。

aws.amazon.com

Microsoft Azure

  • メモリ4TBのインスタンスも既に利用可能になっている

azure.microsoft.com

  • Mシリーズは、ベアメタルインスタンスのため、年額課金となることに注意。開発環境では、Gシリーズの方がよさそうってことかな。

ascii.jp

Google Cloud Platform

  • 東京リージョンの開設(2016/10)

ascii.jp

  • Google × SAPの戦略的提携発表(2017/3)

  • SAP認定を受けたインスタンスが登場(SAPNote.2456432)(2017/5)

  • 海外の事例で、HANAの稼働実績あり

IBM Bulemix

  • Softlayerとのメニュー統合 (2017/2)
  • HANA稼働インスタンスは以下のリンクから

最近では、あまり動きがないようです。IBM との戦略的協業は発表されているものの、Watson との連携だけ。 ちなみ、Watson は、Bluemix にあるものだけが、Watson ではないので念のため。詳しくは、IBMさんに聞いて下さい。

SAP Cloud Platform

  • SAP HANA Cloud Platform からの名称変更(2017/2)

www.publickey1.jp

news.sap.com

  • Google Cloud Platform への展開の発表(2017/3)

  • 東京データセンターでの運用開始(2017/4)

cloud.watch.impress.co.jp

まとめ

最近、以下の記事が公開されました。SAPの方向性を示しているようです。

ascii.jp

あと、SAP×クラウドのまとめは以下が詳しいですね。

www.beex-inc.com

AWS Certified Solutions Architect - Associate を取得しました

f:id:o_chicchi:20170610031134j:plain

はじめに

AWS 認定ソリューションアーキテクト – アソシエイトレベル を取得しました。ようやくです。さっさと取れよと自分に突っ込みたかったです。

aws.amazon.com

https://www.certmetrics.com/amazon/public/badge.aspx?i=1&t=c&d=2017-06-01&ci=AWS00196028www.certmetrics.com

以下にやってきたことをまとめます。 おことわりしておくと、単純に試験だけならここまではしなくていいと思いますが、今後の自分のコアの技術の一部にしたいという思いもあったので、かなり過剰にやってます。あとは、社内にまったく経験者がいなかったので、頼る人が、あまりいなかったというのもあります。

本格的に勉強するきっかけ

以前、担当させていただいたお客様が、AWS でシステム構築をされ、それに興味を持ったのがきっかけです。事例集に載った案件です。立ち位置的には、直接担当する訳ではないものの、お客様の作業支援や、運用に入ってからも少しお手伝いさせていただきました。実は、AWSアカウントは、その案件を担当する以前から取得はしていたものの、なかなか活用できていなかったのが実情でした。

その案件では、自分が複数のチームの技術支援というミッションだったので、とても忙しく、AWS に直接的に関わるという訳にはいきませんでしたが、自分が興味があったのもあり、あいまに、お客様に、いろいろ見せていただいたり、教えていただいたりして、とても勉強になりました。今でも、そのお客様には、感謝してます。

そのあと、別案件の仕事で自分で構成設計、構築もやり、社内の検証環境の設計と環境構築もしたので、その過程で学習できた部分が多かったというのはあります。

書籍

自分でも書籍はずいぶん買って読みました。読んだ書籍を並べてみます。個人的には、「Amazon Web Services完全ソリューションガイド」がとても気に入ってます。それ以外も、ほとんど読みました。改訂版を買い直したものも。大半は読みながら、実際設定してみて、ポイントなどを掴んでいます。

今は、ソラコムの社長になった玉川さんが、起業家として載っているものがあったり、印象的でした。 持ち歩く書籍は、Kindleとかで買い直したいですね。

トレーニング

Architecting on AWS のトレーニングを受けました。AWSではなく、日立インフォメーションアカデミーで受講しました。 というのは、ドル建てクレジットカードで払うところが、私の勤務先の事務処理の都合上、難しかった為です。 (珍しく、二つ返事で費用出してくれました)

https://www.hitachi-ia.co.jp/course/intro/license/aws/intro/www.hitachi-ia.co.jp

先生は、合格対策 AWS認定ソリューションアーキテクトの著書で有名な大塚康徳さんで、サイトに写真があります。内容は、ディスカッションもあり、とてもためになりました。

ラボ

トレーニングでもラボやりましたが、個人的にもその復習と共にセルフベースラボもやりました。 成果はあって、操作系のところは、ほぼ問題なくできるレベルに。

一番苦しんだところは、ELBのところ。概念は分かるのですが、設定項目が画面のどこにあるのか理解するまで時間かかりました。 試行錯誤して理解に至りました。

aws.amazon.com

オンラインドキュメント

AWSのサイトにあるサービス資料集、事例集、よくある質問の確認、オンラインセミナー、勉強会への参加など、限りなくやっていた気がします。

aws.amazon.com

試験対策

試験対策は、トレーニング時の資料もそうですが、セルフベースラボでさんざんはまった部分の確認とか、対策本を改めて読み返す、サンプル問題、模擬試験の内容の復習をやりました。

試験

試験は1回けっこう前に受けていて、それは受からなかったので、今回は、AWS Summit Tokyo 2017 の会場で受けることにしました。ついでにいろいろ見てきたりして楽しかったです。試験自体は、ひっかけ問題が多かった印象ありますね。でも、基本的な知識おさえておけば、なんとかなるのではないかと。

ELB周辺と、リージョンやゾーンについてしっかり学習することろお勧めします。

今後

まずは、Professional レベルの取得を目指して、まずはサンプル問題やるところから初めています。より広くサービスの理解を求められるので、もっと知識を深める必要がありそうです。その先は、全ての試験項目の制覇と、他に取り組んでいるクラウドの資格取得です。

aws.amazon.com

あと、Summit 行ったときに、AWS Lambda の書籍を買ったので、いろいろ触ってみようかと思っています。

今後受ける人へのアドバイス

以下のポイントをおさえておくことが重要だと思います。

  • 試験準備として示されているドキュメントには目をできるだけ通しておく
  • オンラインセミナーで公開されているドキュメントを確認する。
  • ラボで、実際に設定してみる。試験のクエストをやる。
  • 自分でアカウント取って試してみる。
  • サンプル問題、模擬試験をやってみる。

自分への次回の試験に向けても実践していきます。

追記

このスライドも是非、見ておきましょう。

AWS Summit Tokyo 2017 発表メモ

AWS Summit Tokyo 2017 やってますね

相変わらず、仕事していて行けないのですが、AWS Summit が、品川プリンスホテルでやっています。 ちょっと注目の発表があったのでメモ

AWS blogより

aws.amazon.com

皆様にうれしい発表があります。AWSは2018年に大阪に新たなリージョンを開設します。

本リージョンは、ローカルリージョンと呼ばれる新しい設計概念のデータセンターです。AWSのローカルリージョンは、旧来の単一データセンターのインフラ設計とは全く異なる、耐障害性の高い単一のデータセンターです。AWS アジアパシフィック(大阪)ローカルリージョンは、東京リージョンと連携して利用いただくことを想定しています。

東京リージョンには3つのアベイラビリティゾーン(データセンター群)を用意しているため、お客様はいずれか一つのデータセンターで障害が発生した場合でも支障をきたさない、耐障害性に優れ高い可用性を持つアプリケーション構築が可能となっています。

IT資産に対する災害対策として国内に地域的な多様性を重要視するお客さまは、東京リージョンを補完する形で大阪ローカルリージョンをご利用いただけるようになります。

当初、AWS アジアパシフィック(大阪)ローカルリージョンは招待制になります。詳細は、開設時期が近づきましたら改めて発表いたします。

一部のお客様だけだとしても、大規模導入する国内ユーザには、朗報ですね。たぶん、これ、AWS Japan の人が、本国にリクエストあげた気がする。 Azure に負けている理由って、これに尽きるから、あまり使わないにしても、大阪にBCP拠点開設できれば、それで日本の大企業のお客様は、いろんな人を説得できるので。

個人的には、東京リージョンのオプションのAZでもいいと思うんだけど。

大阪作って、きちんと東京リージョンみたいにしても、使うユーザーは意外に多いとは思うけど、管理、面倒なんだろうなぁ。 他の拠点と比べて、数百kmしか離れてないし。

まぁ、続報を楽しみにしましょう。

そのほか気になること

プライベート、社内の仕事*1では、東京リージョン使ってないんだよね(笑) 個人的なVPSは、さくら愛用中。

仮想デスクトップですね。これは、試してみたい。

明日に続く。

追記

www.itmedia.co.jp

  • 準拠法に日本を追加可能に
  • 日本円を含む12ヵ国の通貨での決済
  • コンソール完全日本語化

ツイートみていて

今の仕事辞めて、AWS の仕事に転職しようかと思うこの頃。AWS だけじゃないけど、クラウドサービス、どれもこれも、けっこういじってると面白い。(AWS、Azure、Bluemix、GCP、SAP Cloud ...etc...)

現職(厳密には、現参加プロジェクト*2)は、AWSに関係ないので、AWS Summit にもロクに行けないし、他のカンファレンスもあまり行けないし。このままだと、ラスベガスとか、サンフランシスコに、仕事で行けるのはいつになることか...。

人生は一度しかないので、考え込むこの頃です。

補足

*1 普段は、SESで客先常駐なんですが、うっすらですが、社内の仕事も持っていて、リモートで作業支援したりしています。

*2 今の担当のお客様は、パブリッククラウドが嫌みたいで、プライベートクラウドが良いのだそうです。5年契約拘束されるプライベートクラウドって、何がいいのか、私にはさっぱり理解不能。これは、クラウドですと言って売る大手通信会社の神経がわからん。

Copyright © 2002-2015 まりぱらおーぐ All Rights Reserved.