読者です 読者をやめる 読者になる 読者になる

雑なA型によるクラウドとモバイルと運営と

大阪でJAWS-UG OSAKAとInnovation EGGを運営している人のBLOGです。時々更新します〜

PagerDutyを導入してから1年と4ヶ月 現場の現在(イマ) 運用編&これから

NO OPSという言葉が嫌いで、サーバレスな時代がきたら、

インフラエンジニアが消えるのではなく
まず運用を意識できない開発者(※1)が消えると思いながら、
サーバレスをcloudpack大阪内で推進する比企です。

 

NO OPSの話しをしたいのではなく、今回の話しに出る運用を支えるバックエンドがPaaSやFaaSを使っているので少し記載させていただきました。

 

大阪のMSP開発ではPaaS(FaaS)・SaaSの利用を考えるところから始めます。
運用のコストももちろんですが、開発もコストであるところから、車輪の再発明はしないがキーワードなので、単純にプログラムをガリガリ描きたい方は向いてないかもしれません汗。

というところで今回はPagerDutyの運用からその先の話です。

 

通常の運用時のPagerDutyの課題として

【cloudpack 大阪 BLOG】pagerduty始めました・・・[イレギュラーな事態が発生した時の対応方法その①] - 雑なA型によるクラウドとモバイルと運営と

【cloudpack 大阪 BLOG】pagerduty始めました・・・[イレギュラーな事態が発生した時の対応方法その②] - 雑なA型によるクラウドとモバイルと運営と

などもあり使った所感は下記

PagerDuty始めました 導入から二ヶ月実際のところどうなのPD?【cloudpack 大阪 BLOG】 - 雑なA型によるクラウドとモバイルと運営と

の記載がありますが今回は記載してないお話。

 

PagerDutyの利用料の増加

PagerDutyは便利ですが、利用者数が多くなると、利用料金がどんどん高くなってきます。
https://www.pagerduty.com/pricing/
普段運用のメンバーはインシデントがエスカレーションされるのでもちろん必須ですが、
運用と構築のメンバーが分かれているケースだと、どんどん人数が増えていくので、
注意が必要です。

構築メンバーPagerDutyを必要とするケースは、
①PagerDutyの設定とテスト
②定期的に確認するインシデントの全体量と傾向
ですが、①は設定も難しくなく、PDの設定自体は10分もいらないので、やるメンバーを集約できますが
②に関しては見る人を減らすわけにはいけないので、
Amazon Elasticsearch Service + kibana にLambdaから定期的にデータを突っ込んで
可視化するようにして、見る為だけのユーザー数を減ら為と、

AWSのMSP資格取得時にも必要となるインシデントの負荷情報のトレース(
毎月のインシデントを出力し、MSPのリーダー達がそれを見て負荷情報を確認・対応する)
の為の情報もPagaerDutyから抜き出せるようにしました(pagerdutyでも分析するモードはあるのですが、エビデンスを残すのは無理なのでエビデンス用の情報にフォーマットを加工して出力する機能も搭載)。

 

f:id:unioce:20161024134953p:plain

f:id:unioce:20161024135020p:plain

また上記のシステムにより引き継ぎ時の時間帯にslackへの投稿し、直近のインシデントの負荷状況も
次の担当者の引き継ぎを客観的な数字で連携することも可能としました。

f:id:unioce:20161024134651p:plain

 

 

PagerDutyの利用者による設定漏れとPagerDutyの瞬間的なサービス不通対応
PagerDutyは便利ですが、設定をミスっていたらもちろんインシデントは登録されません。
またPagerDutyは結構安定していますが、それでも100%のサービスを保証していないので
弊社側でシステムとして保管する必要があります。
そしてアラートメールは必ず飛ぶ設定をしますので、アラートメールをlambdaでhookし、
PagerDutyのインシデント状況をAPIで確認し、登録されてない場合はslackに投稿される&
未設定のインシデントということで、再度PagerDutyに登録してMSPのメンバーにエスカレーションされるように
システムを構築しました。
アラートメールの設定が漏れているとこの仕組みで検知はできませんが、それでも機械的にpagerdutyの設定漏れと
pagerdutyのサービスの漏れをある程度のタイミングで検知できるので、有効に機能しています。
 

・インシデント管理以外の活用
弊社は通常backlogでお客様とやりとりしていますが、24時間365日一人一人がつきっきりで見ることはできません。
また複数人で対応していますが担当者が未設定でお客様が登録すると漏れやすい状況となります。
なのでlambdaを利用し、担当者が時間外の場合(設定者のみ)、および担当者が未設定のものや担当がMSPグループに設定されたものは
slackとPDに登録されるようにシステムを作りました。
また運用に使っているGoogleカレンダーのイベント情報もPagerDutyへの登録とslackに投稿する(PagerDutyがクローズされた場合は
slackにも出力される&放置されるとslackにリマインド通知が届き、他の方や登録した人が気がつく)機能も実現しました。

 

上記を踏まえた現在のシステム構成は下記となります

f:id:unioce:20161024134534p:plain

 

現在の取り組みとPagerDutyのwebhooksの課題
PagerDutyでの可視化が行われたことにより、自動化やシステムで補助する監視対象が客観的な数字で追えるようになりました。
完全な自動化は車の自動走行と同じく、なかなか心理的な面で厳しい部分もありますし、
自動化ありきのインフラは論理的にはできますが、実際のニーズと違うケースも多々あります。
なので、現在MSP開発チームではPagerDutyのwebhooksをAPI Gateway&Lambdaでhookして、踏み台サーバーを経由して
自動で問題のサーバーに入り、サーバー内部の情報を取得しエビデンスを残したり、コマンドを実行するARAYASHIKIのαテストを開始しています。
この仕組みを利用しいずれAWSのDevice Farm上のiOSAndroid端末で自動で動作確認を行いそのエビデンスも自動で取得する事も可能となります。
ちなみにARAYASHIKIを実現する時になぜか最初webhooksから登録されていたけど途中から登録されなくなる謎の不具合の遭遇しました。
問題はPagerDutyのwebhooksが3秒以内に応答を返さないとblacklistに登録され、webhooksが無効化されてしまうとの事だったので
pagerdutyに近いと思われるリージョンにAPI GatewayとLambdaの配置をし、Lambdaの中の処理は受付のみで、SNSで再度lambdaを
callするようにしてlambdaの処理時間も最速で非同期で終了するように対応しています。
ちなみにwebhooksの課題は他にもあり下記は特に気をつけたほうがいいです。

さらばHubot さらばEC2。API GatewayとLambdaで始めるMSPのIT化フェイズ3(その1)【cloudpack 大阪 BLOG】 - 雑なA型によるクラウドとモバイルと運営と

こんな活動をtwiter上でつぶやいているのPagerDutyの中の人がわざわざ来てくれて、いろいろと意見交換できて非常に有意義な時間を
過ごしましたが、pagerdutyの世界の利用状況を聴いて、世の中にはまだまだスゲーやつがいるなと再認識させていただきました
(ちなみにプレゼン中に5回スゲーと言っていただきましたw)。

 

今後はPagerDutyで操作するUIでMSPの方がARAYASHIKIで取得したサーバー情報を見て、作業の対応や問題なければクローズするPDへの

操作とARAYASHIKIの情報をMLに学習させ、作業の半自動/全自動化ができるようになり、
本当に集中したい仕事にMSPのメンバーの方々ができるようになればなと思いながら、

あとはMSP開発のメンバー達に託し、自分は2014年8月からのlambdaの
開発/運用ノウハウをベースに9月からチームとしてサーバレスに取り組んでいきます。

 


※1 運用を意識できない開発者
NO OPSで言われるのは単純なオペレーションの廃止ですが、そのほとんどは
開発者が運用を意識せずにシステム開発を行い、その業を運用側が代わりに背負って
日々運用しています。
サーバーレスな時代で、”もし”インフラエンジニアが減れば、
運用を意識できない開発者の垂れ流していたアラートがそのまま壮大なブーメランとなって
帰ってきて、それに耐えきれない運用を意識できない開発者が消えていくと思います汗

インシデント管理システム「PagerDuty」を導入してから1年と4ヶ月 現場の現在(イマ) 導入編 【cloudpack大阪BLOG】

これまでのBLOGでも記載しましたが

インシデント管理システム「PagerDuty」ってご存知でしょうか?
監視対象のサーバーでインシデントが発生した場合、

通常はアラートメールを受信して担当者の方が対応しますが
そのアラート数が、一人で捌ききれない量だったり複数人だった場合・休みの日に通知を受けたくない場合に有効なのがPagerDutyです。
https://www.pagerduty.com/
電話でもインシデントの通知を受け付ける事ができるので、一人運用にも有効です!

日本語での説明は下記BLOGで記載しています。
【cloudpack 大阪 BLOG】pagerduty始めました・・・[説明編]
http://unioce.hatenadiary.jp/entry/20150713/1436787871


cloudpackではPagerDutyを2015年の5月から導入し、

現在に至りますが最初自身一人で導入してからPagerDutyを基盤の

一つとしたMSP開発チームの立ち上げを行い、
MSPサーティフィケート(次世代MSP)の認証も2回認定をいただいた背景の

裏側にはPagerDutyのシステムやデータの可視化が有効に働きました。

cloudpack、AWSのMSPプログラムとビッグデータ コンピテンシーの認定を取得|AWS専業のcloudpack

AWSパートナープログラムにおける『次世代MSP』の認定を取得|AWS専業のcloudpack

 

そんな中、8月に自身のセクションから
大阪の別セクションにMSP開発チーム自体を移動したので、
もう自分のBLOGで新規のアップデートはあまりないなと思い、
今までcloudpackのMSP(開発)内で、どのようにPagerDutyを活用していったかを

記載します。

 

導入の背景
導入当時のcloudpackですでに毎日うん千という、監視サーバーからのアラートメールを
MSPのメンバーがメールを見て、各々が申告して対応していましたが、

多くのインシデントを複数人で
漏れなく対応するのは現実的ではなくなりつつありました。
またcloudpackでは運用の冗長化(DR対策)で大阪にも運用の部隊があるので、拠点を超えての
阿吽の呼吸は事実上不可能で、インシデント管理でのシステム化は必須で、自社内で作ろうとする動きもありましたが、
PagerDutyというインシデント管理システムがあり、監視のSaaSでたくさんの監視サーバーやクラウドのサービスに対応
https://www.pagerduty.com/integrations/
しているので、PagerDutyの導入となりました。

 

試験導入と課題
試験的にまず導入してみようとのことで、10件程のサービスの監視(nagiosとsensu)を行って試験運用してみました。
そこで発生した課題は、下記で記載していますがスケジュールの作成問題でした。

【cloudpack 大阪 BLOG】pagerduty始めました・・・[いきなりの制約回避編 スケジュールとエスカレーションポリシーのハマりどころ] - 雑なA型によるクラウドとモバイルと運営と

cloudpackのスケジュールが特殊とは思わないので、もしスケジュール作成のスクリプトが(
google apps script版でコードは雑w)欲しいいって方は個別にお渡ししますのでメッセージください。

 

本格導入と課題
試験導入で現在の運用に対するPagerDutyの有効性はわかったので、本格運用に入ろうしましたが、ここで色々課題がでてきます。

 

・圧倒的に多い監視対象
2015年5月の時点でnagiosだけで500以上のサービスを監視していたので、手動でやると間違いなくミスをするので
nagiosの監視設定を抽出し、必要な項目をスクリプトに食わして監視設定をスクリプトで自動に対応するようにして実行しました。UIでポチポチなんてやってれません汗

 

・古い監視サーバーへのpagerdutyのpluginのインストール問題
弊社のnagiosサーバーは、複数個あります。多くのサーバーを監視しているサーバーはpluginの導入はうまくいったのですが
古くからある監視サーバーでpluginを普通にインストールするのが厳しいものがあり、本番運用もしているのであえて無理やり
pluginはインストールせずに、メールでのインテグレーションの対応にしました。
https://www.pagerduty.com/docs/guides/email-integration-guide/

 

導入に関してはリアルな運用含め色々と苦労もありましたが、

アラートメールで対応の漏れのないインシデント管理は
我々のようなMSP事業者としてはシステムで対応しなければまず無理なので、

MSP依頼時にはそういうシステム使ってますか?
ってのをまず聴いてみるのもありかもですね(slackで通知を受け付けてますってのは

平和なんだなーと思いますw)。

 

PagerDuty関連でのお仕事のお話があれば是非比企まで連絡していただければ、

ZOOMなどのTV会議でも対応可能ですのでよろしくお願いします〜

次回は運用時からPagerDutyを含めたエコシステムを記載します。

サーバレスアーキテクチャーを運用に適応するために考慮する事【cloudpack大阪BLOG】

PaaSが昔からあるのにLambda+API GateWayが出てサーバレスアーキテクチャーが、もてはやされ出してから時間が経ち、BOT作成人気もあってLambda+API GateWayで試してみた系の話が多くなってきましたが

運用するにあたって考慮すべき話が出てこないので、Lambdaで実現したプログラムを

実際に運用してみて引っかかったり、問題になった部分をちょっと書いてみます。

 

ちなみにサーバレスアーキテクチャーの記事は

や、弊社が出しているLambdaの開発者向けホワイトペーパーは

からダウンロード可能ですので是非みていただければと思います。

 

考慮する点ですが、運用してみた中で、?と思った件があります。

開発時に設定や実装ミスなどもありましたが、エラーが発生せず、
イベントが発火しないケースが存在しました。
問い合わせ時に参考にする記事もあるので一読されることをお勧めします。

 

クラウドではインスタンスが落ちても良い設計をするという話がありますが
サーバレスアーキテクチャーな設計では、エラー時の処理はもちろんの事、
イベントが発火しなかった場合のリカバリーする方法を設計しておく必要があります。

具体的にはイベントが発火しなかった場合、スケジュールの処理などで発火しなかったものを救うなど。
それならいっその事スケジュールの処理で全てすくえば良いって話もありますが、ある程度リアルタイムかつ効率良く処理させれるイベントドリブンな処理は魅力ではあります。

SLA100%ではない現状では、動作しなかった時の検知方法とリカバリー処理は是非とも考えておいたほうがいいです。
※IaaSで実施していた場合も、本当はいろいろあったのですが、

監視方法などが確立され、監視システムのスクリプトなどを

うまく活用して運用してきたのですが、サーバレスアーキテクチャーは

まだこなれてないので、スタンダードな手法がまだ確立されていないのが現状だと思います

 

またシステムの重要度にもよりますが、

Lambdaのメモリ使用量や処理時間などのリソース監視に関しても、注意を払う必要があります。

少しずつメモリ使用量や処理時間が増えていって、ある日突然リソース不足でひたすらエラーに陥いり、あとでリカバリー処理が大変にならないためにも日常のリソース監視

も考える必要があるケースもあります。

 

あとエラーの通知などもよくよく考えずに実装してしまうと、

運用の方がいない場合は開発者の一人24365運用が始まったりします汗。

 

IaaSなどに比べ、開発者にとって、さらにお手軽に実装できてしまう、

PaaSやLambdaですが、運用を考慮した設計と実装を行わないと、

今まで運用している方に押し付けてきたプログラムの未完成さが

フィルターなしにそのまま返ってきます。

 

サーバレスアーキテクチャーやPaaS以上が主流になれば

インフラエンジニアや運用する人は、いらなくなるって極端な話もありますが、

インフラエンジニアや運用してくれる人が、もしいなくなれば、

運用を考慮できない開発エンジニアもその後に淘汰されるってのが

サーバレスアーキテクチャーの案件や、MSP向けのサービスを開発し

運用してきた自分の今の意見です。

 

サーバレスアーキテクチャーで言葉だけではないDevOpsが理解されるようになればと思います。

24365の運用を支える仕組み。PagerDutyを活用する為に【cloudpack大阪BLOG】

最初は自分一人で運用をどう自動化するか?を観点にPgaerDutyの導入から

作業スケジュールのリマインド機能付きslack通知・とあるMSP顧客の各種要望などを
構築/運用業務の傍らにやっていましたが、MSP開発もメンバーが揃いだし、

本格的な開発が可能になってきました。

 

ただ開発者のエゴな車輪の再発明や、

ターゲットが定まってない状態での自動化などの暴挙は行わず

まず運用の可視化や確実性を高めるサービスの導入をひとまず行っています。

※他の現場の可視化が気になって下記勉強会を開催します。よかったら是非

 

cloudpackの運用ではslackをメインにコミュニケーションを行っていますが、
slackの通知はすぐに流れる為に24365で確実に担当者に情報を伝える仕組みとして
PagerDutyをインシデント管理以外も含め活用しています。

非常に便利なPagerDutyですがPagerDuty自体の設定を担当者がミスしていたり、PagerDutyがSLA100%を保証していないのでPagerDutyが正常に稼動しているのか?を監視する必要があります。

その方法として、cloudpackではPagerDutyのサービス障害が発生を想定してアラートメールも併用して冗長化していますが、MSP開発ではアラートメールの内容とPagerDutyの状況を突合させて設定漏れやPagerDutyが正常に動作しているか?を SESの受信とLambdaを利用してチェックし、PagerDutyが正しく動作しているのかを別の観点からチェックする事を可能にしました。

f:id:unioce:20160509134743p:plain

 

MSPはcloudpackのビジネスの根幹です。

お客様に24365のサービスを提供する為にSaaSのサービスを活用するのは必然ですが
利用しているSaaSのサービスが正常に動いていませんでしたって言い訳はお客様にはできないので、MSP開発では日々様々な改善を模索し、開発を行い作成した機能の運用も行っていき、MSPのクオリティを高めていければと思います。

 

 

 ※1 除外設定PD登録のLambdaはアラートメールはあるけどPDに登録されてないものを

PDに登録するLambdaです。

このLambdaで登録されたインシデントはPDに登録された瞬間に自動でクローズされ、突合する時の情報の為だけにPDに登録されます。

この機能により、PDのインシデント登録情報=アラートメールの状態となり、

PDのインシデント登録情報≠アラートメールの場合は漏れとして扱われます。

 

IoTはバズワードか?を確かめたくて開催したInnovation Egg 第六回

IoT AWS CLOUD Google Cloud Platform JAWS-UG SoftLayer Twilio クラウド モバイル 勉強会 基調講演

去年の9月ごろ「IoTはバズワードか?」と色々と思う事がありました。

 

僕の「IoT」が電子工作の域を出なかった理由 - ニートの言葉

なBLOGの投稿がバズっていましたが、自分の経歴である

オープンシステム系開発→制御系開発→モバイル端末開発→

エンタープライズ開発→クラウド運用→運用系開発

と移ってきたときに制御系開発/モバイル端末開発が

シリアルケーブルやLAN・3Gなどに接続されている環境で育った中で

ラズパイにセンサー繋いでクラウドにつなげてクラウド側で様子を見る電子工作の延長に、何ら目新しさを感じず、日本の製品開発のシビアをさを経験した自分からしてみたら、本当に工作レベルの話でした。

なのでIoTをビジネスとして捉える場合、シスコが提唱しシスコの八子さんが

わかりやすく語ってくれるIoEに関しては初めて聴いたときに、

ああこれなら理解できるって感じで、比企のIoTはIoEでした。

 

そして関西のIT業界やデバイスメーカーの方にもIoEを知って欲しいなと思い

八子さんに打診し、

を開催する運びになりました。

9月から数ヶ月たち少し状況は変わり、あれIoTってバズワードでは

無くなってきているなと感覚的に感じる事が身近で多くなり、

9末のSORACOMさんのサービス開始などの発表を受け、IoTの繋げる環境が

容易に手に入る状況になってきました(まだまだLTEのモデムなどは

高い状況にありますが、LTEのIoTやMtoM向けの通信規格だと

非常に安価になるようなので更にどうゆう敷居が低くなります)。

 

そして年初めにはメーカーの多い関西の特性を生かして

IoTの新しいイノベーションが生まれるかわかりませんが、

IoTというキーワードで人や企業が繋がって新しい関係性が作れればと思い

Facebookに「関西オープンIoTグループ」

https://www.facebook.com/groups/447677528759870/

というグループを、関西のハッカソンの盛り上がりを作り出している

元公務員で今は企業された角さんやハンズオン系の勉強会や

生徒にもITを教えている吉田さんと上記グループを作成しました。

※非公開ですが、参加資格はIoTに興味のあって前向きに語り合える良識のある方が

  参加資格です(関西じゃない人も入れますw)。ひねくれたものの見方をして

  問題点だけ語って建設的な発言をされない自己満足な方は参加できません。

 

そして開催二日前のSORACOMさんの

で、C・D・E・Fの各サービスをストリーミング配信で見たときに

更にIoTが身近になったというか、IoTの範囲を超えてIoTを

包み込むようなSORACOMさんのサービスを発表を聴いて

更に色々と考えるようになりました。

※発表時にさくらのIoTも実はSORACOMですって電撃発表を受けた時に

  SORACOMの片山さんとさくらインターネットの小笠原さんが同時に

  登壇する場所を関西で作れたのは非常に胸熱でしたw

f:id:unioce:20160131165214j:plain

 

そして開催当日です。

開催の様子はTwitterで #IEGG で検索していただければ少し様子が

伝わるかと思いますが、 

 

八子 知礼さんの「 IoTで日本から世界に再挑戦!  」

f:id:unioce:20160131164930j:plain

Innovation Egg presen_160130

 

※以降の方の写真は https://www.facebook.com/InnovationEgg/ でw

 

SORACOM-UGから株式会社ソラコムの片山 暁雄 さんの

大阪Innovation egg 第6回資料:SORACOM AirやBeamそして新サービスについて


Twiliojp-ugのcloudpack大阪(iret株式会社)の高橋 慎一さんの

IoTの原点

 

関西おうちハック/GCPUGの株式会社バスキュールの松本 雅博さんの

GCPでお手軽IoTに挑戦


自作デバイスをmyThingsにつなごうインフラからみたDevOps勉強会の株式会社IDCフロンティアの大屋 誠さんの

Innovation egg6 mythings


ハンズラボ株式会社の田部井 一成さんの

ハンズラボの考えるIoT Innovation EGG 第6回 『IoT 今と未来』

 

新規AWS開発系ユーザーグループAWSceanからcloudpack大阪(iret株式会社)の青池 利昭さんの

業務系エンジニアがIoTに触れて感じた事

 

JAWS-UG 関西 IoT専門支部 の 株式会社KYOSOの辻 一郎さんの

[JAWS-UG関西IoT専門支部] IoTで関西のコミュニティをつなぐ


Node-REDユーザー会で日本アイ・ビー・エム株式会社の北瀬 公彦さんの

Try IoT with Node-RED

 

GCPUGでGoogle Incの佐藤 一憲さんの

Having fun with Google Cloud + RasPi // Speaker Deck

 

さくらクラブでさくらインターネット株式会社の小笠原 治さんの
「さくらがIoTってなにやんの?   」

 

と怒涛のセッション内容でした(innovation EGGの状況は他の方がBLOGに書いていただけると期待)。

 

特にGoogleの佐藤さんのデモはただ繋げるではなく、googleのサービスと連携させて

デバイス単体では不可能な内容を見せて頂き、会場からこういうのもあるのか?

と驚きが出ていました。

 

懇親会も盛況で、今までInnovation EGGに来たことがない方も参加しており、

関西以外からも名古屋・東京・四国と遠路はるばる来ていただいていました。

 

懇親会の席も非常に盛り上がったのですが、懇親会の席でデバイスメーカーの方が

「IoTを自分たちがするかを選択できる時代ではない。IoTな世界になった時にどう自分たちの市場を守っていくのか?」と、言われていて、

自身が日本の携帯電話開発をしていて、日本携帯が全盛期のころにiPhoneが現れて、

未完成なAndroidgoogleから発表され自身もAndorid端末の最初のほうに開発をしていた時に、「Androidはいずれ日本の携帯電話市場で日本メーカーの優位性をなくしてしまう。これからはクラウドの時代だからクラウドに移行する」と決断した時に

逆らえないIoTの波の中でどうデバイスメーカーが戦っていくのか?というのに対し

近親感を覚えました。

 

IoTは参加する立場によって様々な入り方があり、WEBの開発者がラズパイを触って始めるのと、デバイス側の方がクラウドによっていくのは全然別のアプローチ・感覚になりますが、WEB側の人とデバイスメーカーの人が入り方は違えど同じエリアに入って

色々と議論し、たとえIoTでなくても新しいinnovationやビジネスが生まれれば Innovation Eggや関西オープンIoTグループは運営する価値はあるのかなと、

この頃自分自身はIoTの定義をあまり考えなくなってきたわけです。

 

Innovation Eggは秋頃にもう一度IoT関連の事をしようかと思っていますが、

デバイスメーカーの人や、まだクラウドに触れていない人のために

開発者向けAWSユーザーグループのAWScean(直近では2月27日にTwiliojp-ugと同時開催)

https://awscean.doorkeeper.jp

 

で、AWS縛りになりますが(範囲を広げると大変だと思うので)、

デバイスメーカーの方含めた非クラウド系の方向けに開催しようかなと思っています。

 

最後に

2000年前半あれほど売れていた日本のモバイルメーカーは

数年で現在の状況になりました。

端末のスペックでは世界一と言われた時もありましたが、携帯電話としては

当時未完成だったAndorid端末にどんどんと侵食されていきました。

日本のセンサーは世界的に精度が高いと言われていますが、

クラウド側とつながったそこそこの精度のデバイスが、現在の状況を

ひっくり返す事は無いとは言えません。

 

IoTはバスワードかどうか?なんて議論は評論家に任せておいて、

自分達のIoTはどうなのか?を自分自身で考えていただければと思います。