再会の日 ~re:Union 2018 Osaka by JAWS-UG~

Tweet

8/5は大阪でre:Unionでした。

「再会」と名うったこのイベントは、6月に中止となったあの大阪初のイベントで予定されていた登壇者とコンテンツをお話いただく場所になりました。

受付開始の1時間前の9時頃に会場ご提供いただいたMOTEXさんにぼちぼち集合しました。

そして受付準備をして最初の頃は受付をしてました。

そしていよいよ、濃密な1日のスタートです。

以下は、思ったことや気になったことをメモしていますので、必ずしも登壇者の発表内容やご意見ではないことを、ご承知おきください。

SUMMIT TOKYO re:cap〜基幹システムの移行とクラウドネイティブ構築、それぞれの事例のお客様をお迎えして〜

AWSJ 亀田さん

EFSのプロビジョンドスループットで保存容量に応じた性能を出せる。

SageMakerは基本的にデータサイエンティスト向けのサービスだがデータサイエンティストじゃなくても操作できる。
開発/学習をコストの低い海外リージョンを使用して、推論は近いリージョンという使い分けができる。

Lambdaはイベントドリブン型でステートレス、Fargateは実行時間に制限がないのでステートフルな使い方も可能。
FargateはECSのサーバー管理部分を完全に抽象化している。
コスト差はある。マネージドなのでEC2タイプで出来る詳細部分はさわれない。

ユーザーの相関関係をRDBで実現しようとすると無理が出てくる。それを扱いやすくしているのがグラフデータベース、そのマネージドがNeptune。

Summit Day1 Keynoteサマリー

2017年で1,470のサービスおよび機能追加。
90%~95%はお客様からの機能要望による。

リージョン間の通信のアップデート。
VPCインターリージョンペアリング
Direct Connect グローバル
インターネットを経由せずにAWSが敷設した回線を通過するのでパブリックなインターネット回線に出ることはない。

Cloud + Community →情シス2.0

フジテック株式会社 友岡さん

Cloudとコミュニティで情シスをアップデートしよう。

こんないい時代になっているのになんで自分たちでデータセンター作らないといけないのか。

「データセンターを持っているということは発電機を持っているのと同じ。いつまで持っているのですか？」 #jawsug

— やました (@yamamanx) 2018年8月5日

年間19,600円が100円にw #jawsug

— やました (@yamamanx) 2018年8月5日

Well-Architected、クラウドエコノミクスなど

自分たちで出来る範囲を見極めて、どこをパートナーにお願いするかを決めてからパートナーと話しをする。
パートナーから探すのではない。
うんうん。
なので、出来る範囲を増やすのも本当に必要だし、パートナーに協力してもらうことも知っておいたほうがいいんですよね。

位置情報に表現を与えるStroly

株式会社 Stroly 高橋さん

Strolyは、Stroll(散歩する) + Storyをかけあわせた言葉。

オリジナルの地図をマッピングさせることができるからデザイン性の高い地図を公開できるのですね。

ありますよね。Googleマップで住所だけじゃ分かりにくかったりとか、サイトが用意している地図はわかりやすいけど、自分の今の場所がわからない。オリジナルの地図にマッピングしていることでこれの解決もしているのですね。 #jawsug

— やました (@yamamanx) 2018年8月5日

観光情報を掲載している地図があるのに、それをGoogleマップで再検索しているのはもったいない。そのままの地図を使って案内ができるサービスがあると便利。本当そうですね。なるほどお。

「どんな風にその土地をみてもらいたいのか」かあ #jawsug

— やました (@yamamanx) 2018年8月5日

カフェスペース

そしてここから10Fに移動してカフェスペースの店番担当です。
と言っても何かするわけでもなく、誰かが一応いないといけないのでいるだけです。
2Fの登壇の中継を見ながら、コーヒー飲んだり、お菓子食べたりしてました。

このケータリング一式はAWSJさんからのご提供でした！
ありがとうございます！

セッションの合間の休憩時には、賑わっていました。

ここからは主に10Fからセッションを見ていた感想をお届けします。

Lift-and-Shift による失敗しない AWS 移行のやり方

株式会社サーバーワークス 大石 さん、株式会社NTTスマイルエナジー 川村さん

まずは移行しやすいサービスを使ってそのまま持っていく。そうすることで運用や組織を大きく変えなくてもAWSヘ移行できる(Lift)。そしてAWSらしい使い方へアプローチしていく(Shift)。 #jawsug

— やました (@yamamanx) 2018年8月5日

AWS 上で実現する機械学習システムの構築と運用

AWSJ 桶谷さん

データ収集および活用に関するサービス

StepFuntionsで機械学習のモデル更新からデータ加工を自動化する、ってこれはタスクとしてLambdaを実行していくってことですよねえ。

武闘派 CIO プレゼンツ！ つながっていないモノをつなぐ「荒ぶる IoT 」実践講座

フジテック株式会社 友岡さん

「IoTやるぞー」のイメージはゴジラが吠えて、みんながエライコッチャってなっているイメージw

だめな事例としてイノベーションセンターでPoCをやって何にもならなかったこと。簡単に出来るからといって安易すぎる手をつけて、誰も賛同しないのはだめな事例。
緒戦で圧倒し一人でもいいから熱狂的なユーザーを作ることが大事ですと。

IoTの分かりやすいメリットは繋がっていなものがつながり、見えなかったものが見えていくこと。
このメリットを活かしやすい条件は、距離が離れている、担当者が違う、インターネットに繋がっていないデバイス、これをつなげることで、課題解決につながる。

「つながらないものを強引につなげる」 = 「荒ぶるIoT」
これにはテクノロジーだけではなく、根性も必要らしい。
そうですよね。きっとそうですよね。
IoTやろうぜってだけで出来るものではないですね。
でも、だからといって、頭の中だけで諦めていたら本当は叶うことさえ叶わなくなっていくんですよね。

多様性を容認し、統制よりも自主性を重んじて、規制よりも自由を重んじる。その中で価値を生み出す人を徹底的に支えて、必要なツールを与えて共感者を増やし感染させるようにキャズムを越えていく。
この考え方、まさしくそうだと思っていて、使いたくないものを押し付けても誰も幸せにならないので、本当に使いたい、エンジニアが自分たちにマッチすると思っているものを使うべき。
極端な話し、一人一人が違うツールん使っていても目的が達成できるのであればウェルカムなはず。
統制も目的を阻害するボトルネックにしかならないのであればなくてもいいはずなんですよねえ。

自主性だけではなく、会社が必要な面(お金、ツール、ルール)で支えることは本当に必要です。(勝手に勉強する、提案、自動化、など)都合のいいところだけ放置しつつ、クラウド以前の型通りのルールで抑えつけたあげく「成果につながらなかった」はちとひどい話。これも一つのつまずきポイント。 #jawsug

— やました (@yamamanx) 2018年8月5日

Nintendo Switch (TM) 向けプッシュ通知システム「NPNS」

任天堂株式会社 渡邉さん

1億台のデバイス(Switch)に耐えうるスケーラビリティアーキテクチャとのこと。すごい。

MySQLからAuroraへの乗り換えをされた事例。
一悶着あったらしい。

スケーラビリティはクラスタ数変更で対応、なので1クラスタあたりのノード数は小さく構成している。そうすることで安定性を向上している。

プロトコル的にNLBが使えたが、リリース時期と検証時期があわなかったこととクロスリージョン対応がないことで見送り。

Route53のDNSラウンドロビンでロードバランスしている。
Route53に全ノードのAレコードを登録して、Consulにより更新している。

AutoScallingは異常のあるインスタンスの置き換えに使っている。→耐障害性の向上。

ドリップ処理だけではなくBlue/Greenデプロイはデプロイ時のインスタンスが倍になるのでコストが2倍になる。
DNSを切り替えたあとにドリップ処理。

切られたSwitchは自動的に再接続するのでGreen側に接続していく。
一気に負荷をかけないようにしているんですね。

R3.largeで1台あたり72万台接続されている。
Security Groupのセッション数に制限があった。
Security GroupでAll Trafficでワイルドカード(0.0.0.0/0)にすること(無効にすること)で接続数を増やしたそうです。

同時接続が増えてもクラスタのスケールによって耐えられている。
約700万同時接続。約2万通/秒、約200億通/月

AWS側の異常についてもオートスケーリングによってサービス停止にはならなかった。

AWSを活用したIoTプラットフォーム開発

ダイキン工業株式会社 古川 さん

ダイキンさんでSREを担当されているそうです。
150カ国とは名前に違わないグローバル具合ですねえ。
GPF(Daikin Global Platoform)とは全世界の空調機をインターネットにつないで、ライフサイクルに対するサービスを提供するプラットフォーム。
GPFではAWSをフル活用されている。

疎結合コネクタとしてkinesisを使われている。

DynamoDBの設計プラクティスとして、クエリ中心の設計へ、と。

そして、1アプリケーション = 1テーブルで設計。これは1機能1テーブルということですよね。そして機能はマイクロサービス。なのでマイクロサービス間の整合性はDynamoDB Streamで担保されている。

ソートキーにコンポジットキーとして値を格納する。
アンダースコアでつなぐことで3属性以上の複合キーをDyanmoDBで実現されている。

“AIアナウンサー”による、ラジオの再発明

特定非営利活動法人エフエム和歌山 山口さん

地方の生活に密着した詳細情報を臨時災害FMでは提供されている。
臨時災害FMの課題は
* 地域唯一のメディア
* 未経験ボランティアが従事することが多い
* 誰も周波数を知らないところからスタート
* 地方ではプロのアナウンサー確保は難しい

情報量が多いのは採用理由として大きいです。#jawsug

— やました (@yamamanx) 2018年8月5日

プロのアナウンサーを求めているラジオの世界でPollyが採用された。

「細かいコントロールは出来ないけど要らない」これマネージドサービス全般でいえること #jawsug

— やました (@yamamanx) 2018年8月5日

構成はけっこうなハイブリッドですね。
本当に必要な機能のうち、AWSでしかできないことだけをAWSで実現されているように見えました。

出社しなくてもアナウンス対応できる。

今までのラジオは、アナウンスがあるまで待ってなければならなかった。
AIアナウンサーによって、常に最新の情報が流せるようになった。

LexiconよりもSSMLの方が変換優先順位は強い。
雑音の中での聞きやすさ、呼吸音と速さを自動で調整してくれる。
でもMizukiさんは歌はまだ唄えないww #jawsug

— やました (@yamamanx) 2018年8月5日

https://t.co/aQuEwv3guh #jawsug

— やました (@yamamanx) 2018年8月5日

AWSのサーバレスとコンテナによる新しいアーキテクチャの活用と構築方法

AWSJ 清水さん

直接的に出てきた話ではないですが、「コンウェイの法則」かあ。
「組織はアーキテクチャに従う」かあ。
「ソフトウェアの構造にはそれを作った組織の構造が反映される」とも言われているようですが。
結局のところ、組織ありきではないほうが良さそうですね。組織を守ることが目的ではなく、より素晴らしいサービスを世の中に提供するために考えられたアーキテクチャに組織は準拠するということかと考えました。
そうすることでその組織が世の中にとって必要になると考えると非常に納得感。

SAMのPackageコマンドがSAM TemplateをCloudFormation Templateに変換する。
そしてDeployコマンドでLambdaにデプロイされる。

SAMのサンプルは Githubのawslabsにある。

AWS SAM CLIでは、Lambdaの実行環境をエミュレートしたローカル環境がDockerで提供される。

コンテナのメリット
* パッケージング
* 配布
* イミュータブルインフラストラクチャ

EC2タイプでやること
* OSのプロビジョニング
* OSのセキュリティ

AWS Fargate
* インスタンス管理不要
* タスクネイティブAPI
* リソースベースの価格

ハカルスにおける AWS を活用した機械学習 API の構築と運用

株式会社ハカルス 染田さん

機械学習への取り組みに対して、どのようにプロセスんやチームを考えるか、これはすごく聞きたいお話です。

Machine Learning Meetup KANSAI を立ち上げられた染田さん。

モデル埋込み型とAPI型の違いは、大枠で言うと密結合と疎結合の違い。
疎結合にすると分離は出来るが、運用が一手間増えるとのこと。
なので、ここでもなんでもかんでもというわけではないのですね。
やりたいことに応じて選択していく必要があるのですね。

そして、機械学習の話なので、フェーズは開発、学習、推論について。
いろんなお立場や目線から、いろんなセッションで繰り返し聞いていることで、ようやくこのへんの理解が進んできました。

ソフトウェアエンジニアが担当するのは推論、アルゴリズムの開発、学習させてモデルを構築するのはデータサイエンティスト。

Lambda + DynamoDBも最近仲良くなりましたよね〜ぐらいのお友達感覚でまだいれます #jawsug

— やました (@yamamanx) 2018年8月5日

AWS Night School !! ～AWSの基本サービスを学ぼう 初心者向けセッション、上級者はちゃちゃいれてもいいですよの巻～

AWSJ 亀田 さん

よくこの短い時間でポイントを簡潔におさえて効率よく説明されているなあと思い、勉強になりました。

以下、説明ロジックで参考になるなあと思ったメモです。

AZ間の1msのレイテンシーは技術的に可能だが、大変高額。

S3はEBSに比べて10倍、EFSに対しては30倍のコスト効率。

ありそうなバケットを作っておいて、もう作れません、というクッション。

AWSでは良くも悪くもお客様のデータには一切アクセスしない。なのでデータはお客様が守る。

そのサービスがVPCの中か外かを確認しておくと、頭の中でぼんやりと設計図が書ける。

EC2はスケールしたインスタンスを並列で使う。
RDSはマスタースタンバイ。

Auroraは3AZで6ディスク。

WriterとReaderでクラスタエンドポイント。
Writerの障害時にReaderがWriterに昇格する。
ASGにもReadReplicaで対応している。
まだGAではないマルチマスターはリージョンをまたげる。

懇親会

懇親会にはなんと50名が参加！
新幹線の時間だったので途中で帰りましたが、本当に密度の濃い一日でした！
長丁場でした！
お疲れ様でした！

最後までお読みいただきましてありがとうございました！

【PR】 「AWS認定試験対策 AWS クラウドプラクティショナー」という本を書きました。

【PR】 「AWSではじめるLinux入門ガイド」という本を書きました。

【PR】 「ポケットスタディ AWS認定 デベロッパーアソシエイト」という本を書きました。

@yamamanx

開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター3年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。

また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。