JJUG ナイトセミナー 「Elasticsearch特集」行ってきましたレポート!

JJUGナイトセミナーに行ってきました!
jjug.doorkeeper.jp

初めて日本オラクル本社に行きました!
今回はレポート少なめですが、書き殴っていきます。

Elastic Stackで始めるJavaアプリのパフォーマンス監視

speakerdeck.com

  • Beats
    • データを集めて後ろに投げることが主目的で軽量である。Go言語で作られている。
    • Libbeat
      • カスタムbeatsのためのAPIフレームワーク
      • Packetbeat, Metricbeat, Winlogbeat, Auditbeat, Filebeat, Heartbeat
  • Logstash
    • Rubyで作られている。データ加工パイプライン
  • Elasticsearch
  • Kibana
  • Elastic APM
    • アプリケーションパフォーマンスモニタリング
      • アプリケーションの内部パフォーマンスを可視化
    • ユーザーアクションを計測するRUMというものもある。現在はJavascriptのフロントエンド用
    • APMサーバーが必要。x-pack basicでKibana API UIを構築
    • Python, Node.js, Rubyがサポート。JS, Go Javaはβ提供。
    • elasic-apm-agentでmaven検索で取得できる。

はじめてのElasticsearchクラスタ

www.slideshare.net
結構Deep Diveなセッションでしたので、スライド参照したほうがよいです。

所感

視覚的にアピールできるKibanaはセミナーでとりあげられることが多い。
しかしながら、モニタリングツールは他にもたくさんある。
特にIaaSを利用しているなら標準モニタリングもあるだろう。
既に可視化できる環境を持っているのならば、
Kibanaをモニタリング目的だけで導入するというのは、
判断する人(上司)を振り向かせることが難しいと思う。

むしろ、大事なのは中核をなす機能であるElasticsearchだ。
GitHubの検索に使われているという実績は大きい。

私は今まで全文検索エンジンを利用した業務システムを構築した経験はないが、
この機会に各ソフトウェアやエンジンについてより深く知りたい。

Elasticsearch - Wikipedia
Apache Lucene - Wikipedia
Apache Solr - Wikipedia

ナイトセミナー楽しかった!また来月いけたらいいなぁ。

Spring BootのGradleプロジェクトをJenkinsでCIしてみる

本エントリーは下記バージョンで動作確認しています。

Jenkins 2.121.1
Spring Boot 2.0.1
Java OracleJDK 8

GitHubで管理しているSpring Bootプロジェクトを
Jenkinsでビルドし、ユニットテストを実施してみました。
その時の設定箇所を記載します。

設定箇所

新規ジョブ作成時は「フリースタイル・プロジェクトのビルド」を選択

f:id:yasay:20180706142041p:plain

ソースコード管理でGitHubリポジトリ情報を入力

今回はGitHubからソースをダウンロードしてビルドしますので、
Gitを選択します。リポジトリURLと認証情報を入力します。
認証情報はGitHubのユーザーIDとパスワードを使用しました。
f:id:yasay:20180706142656p:plain

ビルド・トリガを指定。今回は定期的に実行。

cronの書式で入力する。今回は30分に一度ビルドが走るように設定。
f:id:yasay:20180706142959p:plain

ビルド環境の設定

「ビルド開始前にワークスペースを削除する」をオン。
この設定をオンにした経緯は、ビルド後の処理である「テスト結果の集計」で
日付の古いxmlファイルを見ようとしてビルドエラーになってしまったためになります。
f:id:yasay:20180706154355p:plain

ビルドタスクの追加

  1. 「ビルド手順の追加」 -> 「Invoke Gradle script」を選択
  2. 「Use Gradle Wrapper」を選択し、「Make gradlew executable」にチェックを入れる。
    • 今回はGradle Wrapperを使用しています。"gradlew bootJar"などのコマンドを実行することで、Gradleをインストールしていなくてもビルドなどを実行することができます。
  3. Tasksの入力項目に"bootJar"と入力します。

f:id:yasay:20180706143705p:plain

テストタスクの追加

前項のビルドタスクの追加と同様の手順を行った後、
Tasksの入力項目に"test"と入力します。
f:id:yasay:20180706143853p:plain

JUnitテスト結果の集計タスクを追加

  1. 「ビルド後の処理の追加」 -> 「JUnitテスト結果の集計」を選択
  2. 画像を参考にして、テスト結果xmlファイルのパスを指定する。

f:id:yasay:20180706154720p:plain

さっそくジョブを起動してみます。成功しました!

f:id:yasay:20180706144751p:plain

ユニットテストの結果を確認することも可能です。

testコマンドは標準でhtml出力されるようで、下記の手順で閲覧することが可能です。

  1. ジョブのワークスペースを選択する
  2. 「build / reports / tests / test」に移動するf:id:yasay:20180706145051p:plain
  3. index.htmlを選択する。f:id:yasay:20180706145159p:plain

テストサマリーが表示されました!

今回はVagrantとDockerで起動したJenkinsサーバー上で動かしました。
気軽にCIを実践できるよい時代になったものですね!

以上です!

VagrantでJenkinsのDocker Imageを起動する

手元のPCがあれば、いつでも始められるCI!

Vagrantの初期セットアップは下記の記事をご参照下さい。
xblood.hatenablog.com

DockerでJenkinsを起動する

Docker Imagesの取得

sudo su
# JenkinsのLTSイメージを取得する
docker pull jenkinsci/jenkins:lts

Jenkins Imageをバックグラウンド起動する

# -vオプションで、コンテナが停止した時のためにJenkins関連ファイルを永続化する
# --restartオプションで、vagrantが起動した時に自動起動するように 
docker run -d -v jenkins_home:/var/jenkins_home -p 8080:8080 -p 50000:50000 -e "TZ=Asia/Tokyo" --restart=always jenkinsci/jenkins:lts
自動起動を停止させたい場合
# Nameをgrepで取得する
sudo docker inspect -f "{{.Name}} {{.HostConfig.RestartPolicy.Name}}" $(sudo docker ps -aq) | grep always
# update --restart=noを設定する。引数となるのはコンテナのNAME
sudo docker update --restart=no $Name

コンテナIDを確認する

docker ps
# 以下のような結果が表示される
CONTAINER ID        IMAGE                   COMMAND                  CREATED             STATUS              PORTS                                              NAMES
850da8fef9f2        jenkinsci/jenkins:lts   "/sbin/tini -- /usr/…"   7 minutes ago       Up 7 minutes        0.0.0.0:8080->8080/tcp, 0.0.0.0:50000->50000/tcp   nostalgic_lamport

コンテナIDを指定してコンテナ内に入り、初期パスワードをメモする

# execコマンドを使用
docker exec -i -t $PROCESSID /bin/bash

# 初期パスワード確認
cd
cd secrets/
cat ./initialAdminPassword

ブラウザからアクセス

メモしておいた初期パスワードを入力し、セットアップを進めます。
無事に初期画面までたどり着きました!
f:id:yasay:20180705145210p:plain

以上です!この続きのエントリーは
「Spring BootのGradleプロジェクトをJenkinsでCIしてみる」になります!
xblood.hatenablog.com

AWS CodeStarで遊ぶ!お手軽に継続的デプロイメント!

AWS Code Starは継続的デプロイを実践する上での近道になるとの認識です。
なにはともあれ、とりあえずCode Starを触ってみて継続的デプロイを実践してみます。

Code Starは複数のCloudFormationスタックの集合体

ですので、Code Star自体をCloudFormationでプロビジョニングするという方法は、
現時点(2018/7/5)では存在しないという認識です。
参考サイト:
dev.classmethod.jp

プロジェクト・テンプレート

これ見るだけでもわくわくするぞ!今回はPHP(Slim)のElastic Beanstalkを選択。
https://dev.classmethod.jp/cloud/aws/about-cloudformation-in-aws-codestar/
f:id:yasay:20180705110056p:plain

GitHubリポジトリを使う

今回はリポジトリGitHubを指定。プロジェクトを作ってみます!
f:id:yasay:20180705110349p:plain

数分でCodeStarのセットアップが完了!

数分でCodeStarプロジェクトのセットアップが完了します!これはすごい!お手軽!
f:id:yasay:20180705111615p:plain

Public IPにブラウザでアクセスしてみる。

繋がった!Hello World!
f:id:yasay:20180705111915p:plain
すぐ繋がるということは、既にElastic IPやSGがプロビジョニングされているということですね。
確認してみると、SGはフルオープンになっていたので、IP制限しました。ネットワーク転送料金怖い。

Beanstalkのアプリケーションエンドポイントでもアクセスできます。

今回はElasic Beanstalkでプロビジョニングしたので、
下記のようなエンドポイントでもアクセスできました。

# URLの例
http://php-beanstalkapp.amXXXXXXXX.ap-northeast-1.elasticbeanstalk.com/

早速プッシュして、継続的デプロイメントを試してみる。

今回はIntelliJ IDEAにPHPプラグインを入れて編集してみました。
"Hello CodeStar!"に変えてみます。
f:id:yasay:20180705113309p:plain

すぐさま、CodeStarにコミット履歴が表示される。

普段この管理画面を見る事自体、あまりないと思いますが、リアルタイム性すごい。
すぐにコミット履歴が表示されました。
f:id:yasay:20180705113513p:plain

継続的デプロイメントが発生!

すぐにデプロイが開始されました。早速エンドポイントにアクセスしてみましょう。
f:id:yasay:20180705113720p:plain

Beanstalkのエンドポイントに接続してみる。変更された!

ちょっと感動した!
f:id:yasay:20180705113836p:plain

気になった点

VPCの指定はできないの? -> できました。

初回はデフォルトのVPCで起動してしまいました・・。
「プロジェクト詳細の確認」画面で、「Amazon EC2の設定を編集」を
クリックすることで指定することができました。

f:id:yasay:20180705114603p:plain

所感

ここまでの作業で30分もかかってないところがすごくて、
本当にAWSリソースのプロビジョニングとアプリケーションデプロイの環境が
瞬時に作成できる。スモールスタートはこれでいいんじゃないかと思う。

しかしながら、懸念は残る。結局AWSのコードサービスを使いこなせるかが鍵かな。
開発環境ならいいんですが、プロダクション環境とかになると話が変わってきますよね。
プロダクション環境だと、サービスが稼働しているわけですから、簡単にはデプロイできないです。
そういった場合のローリングアップデートの方法を知るということは、
AWSのコードサービスを使いこなすということだと思うので、
属人化が発生する可能性がある点かな。

また、AWSのコードサービスに浸かっちゃうと
もし仮にAWS以外でやりたいって場合にどうするの?という話も出てくると思います。
所謂ベンダーロックインというやつですね。AWSにならベンダーロックインされてもいいわぁ。

さくっと作ってさくっとデプロイするにはCodeStarは最強ですが、
実際に運用するとなるとベスト・プラクティスが必要になる気がしました。
だって、実際の運用だとサブネットをプライベート化するじゃないですか。
CodeStarで作られるVPCのネットワーク構成はその辺り考慮されて作られるわけではないんですよねぇ。

以上です!
CodeStarシリーズのエントリーは続くかもしれません、続かないかもしれません!w

Windows 10のデカいアップデートでPhotoshop CS3が使えなくなった場合の復旧方法

古いソフトでサポートも切れてるからしょうがないんだけどさぁ・・(´・ω・;`)。
公式サイトの解決方法で試してもどれも成功せず。
最終手段は再インストールとか、そりゃないでしょ。面倒。

なので、再インストール不要での解決方法を備忘録兼ねてエントリーを残します。

現象

起動すると以下のメッセージが出て起動に失敗する。
f:id:yasay:20180614183149g:plain

解決方法

1. "cache.db"ファイルを削除する

ファイルは下記ディレクトリに存在する。

C:\Program Files (x86)\Common Files\Adobe\Adobe PCD\cache

2. Photoshop CS3を起動して、ライセンスキーを入力する。

ライセンスキーの入力を促されるので、控えておいたライセンスキーを入力する。
f:id:yasay:20180614183752p:plain
無事に起動成功!

以上です!

AWS Summit 2018 Tokyo 行ってきました!Day 2 レポート

Day 1のレポートはこちら↓
xblood.hatenablog.com

f:id:yasay:20180614161307j:plain:w350

Tech系セッションは後ほど動画が公開されたらリンクを貼りたいと思います。
Day 2のレポートを書いていくよ!↓↓↓

Day2 5月31日(木)

09:00-09:40 AWS パートナープログラムのご紹介

  • 日本型の中抜きビジネスは今後通用しない。絶対的な利益額が減り、上流が通じなくなる。
  • 本業集中と内製化。
  • クラウドインテグレーターが1週目は勝利した。
    • 2週目はこれから
  • IT従業員の7割がアプリケーションエンジニアで、インフラエンジニアは3割ほど。
    • クラウドAPIでコントロールするデータセンターサーバー。だからアプリケーションエンジニアにFitする。
      • だが、当初はインフラエンジニアがAWSに振られていた。
  • 会社規模・知名度ではない。プロジェクトマネジメント能力は重要。
  • 自社の強みを世の中にアピール。コンピテンシーを所有していることを証明とか。
  • 成功したパートナーの3つの共通点
    • チャンピオンのアサイ
    • セルフラーニング
    • ダイレクト タッチ
  • チャンピオンのアサイ
    • 会社の中で中心的な人物を
      • 後輩に慕われている、AWSのテクノロジーを詳しく知る必要はない。テクノロジーに詳しい人は別ポジションにアサインすればよい。
      • どちらかというと技術寄り、フットワークが良い、リスクをとって進めることができる。"確認します。"では遅い。
      • プレゼンテーションが嫌いではない。
      • AWSと言えばこの人と言える人
  • セルフラーニング
    • Business Professional Online/Technical Professional Onlineは全員受講
    • 技術者は、Black Belt Onlineセミナー、JAWS UG XXX支部に参加
    • 初心者はAWSSome DayやSTP-Fなどの無料トレーニグを積極的に活用
    • 会社として、受講費用を提供、認定資格を会社が負担
    • まずは触ってみる。アウトプットと共有。その文化。
  • ダイレクト タッチ
    • 自社の強みを磨いて、顧客と直接対話すること。
    • 2020年4月1日 法改正
    • 短納期・Pay per user型
所感

"テッキーな方々"という呼び方面白い。
各社の雇用状況については、やっぱり敏感に反応しておかないといけないよねぇ。自己実現のためにも。

10:00-10:40 AWS の DataLake を使ったデータ分析入門

  • データ活用の考え方、データレイクの考え方、データ活用のための試行錯誤などが主なセッション
    • データを貯める->可視化->分析/ML
      • 試行錯誤のサイクルをいかに高速に回せるか
  • RDB
    • スキーマが定義されている、データの型も強制できる。アクセスするツールが簡単。トランザクションも。
      • スケーラビリティに限界がある。非構造化データに対応しずらい。リアルタイム分析など当たらな要求に対応できない。
      • データのサイロ化による対策。しかしサイロ化の課題も。
  • 全てのデータを生のフォーマットで安全に保持することがデータレイク構想。
    • ストレージと計算処理の分離、SSOT、様々I/O手法に対応
  • サイズ制限からの解放も必要ですData Lakeは。
  • システム全体のハブとして機能する。
  • データレイクのためのAWSサービス
    • 保存:S3
    • 収集:OSS on EC2(fluentd, logstush)、Kinesis、Snowball、AWS IoT
    • 分析:Redshift, EMR, Athena, Glue
    • 可視化:QuickSight, パートナーソリューション(要望によって違うので)
  • 事例
    • Finra, prieNumber(DMP)
所感

システムは改善を止めたら死 = 分かる
これを人生にも当てはめると面白い。
自分自身のキャリア開発を止めたら・・・死ではない。
だけど成長が止まる。成長が止まったらよくない。
つまり、システムであろうと、自己実現であろうと同じベクトルに向ける、それが一番大事!?。
そして、PCに貼るステッカーも改善を止めたら死(ぉ)
・・・サービスのロゴも変わるのでダサい・・必要なシール以外貼るのやめよう。→ めっちゃ剥がしたw

12:00-12:40 AWS のオペレーション最適化の勘所

  • AWS Config Ruleで必須タグの強制ができる。
    • まぁ、しかしながら、タグで全て管理しようとしても無理があることは納得。
      • IAMアクセスポリシーでタグを指定すると大量のタグを指定しないといけなくてポリシーが書けない(文字数制限に引っかかる)とか。
  • AWS Organization
  • AWS Support
    • AWS Suportを利用する場合は、問い合わせするフォーマットを徹底することで対応スピードが上がる。発生日時、リソースなど。
    • リソース毎にチケットは切っていったほうが良い。緊急度も適切に。
  • 請求APIとか、Trusted AdvortiserAPIとか。
  • Personal Health Dashboardも活用してみたい。https://phd.aws.amazon.com/

13:00-13:40 DevSecOps on AWS - AWS のモニタリング-

Dev && Sec && Ops

  • クラウドネイティブセキュリティ
  • AWS上でのDevSecOps実装方法
    • Metrics-Based, Event-Based, Rule-Based
    • Trusted Advisor, CloudTrail, GuardDuty, CloudWatch, Config, Macie
  • セキュリティベースライン作成の考え方
    • MasterにはIAMロール作るけど、子アカウントには作らない。
      • 理由としては、キーのロールとか面倒になるから。
    • Lambdaの集約
      • 管理が簡単。
  • Admin側に情報を集約する方法に、CloudWatch Event Busという手法がある。
    • Admin側にパスされるので、ターゲットアカウントのイベント発生をトリガーにAdminのLambdaを起動できる。
  • Cloudtrailの有効範囲を設定できる。
    • Cloudtrail Realtime report?
  • Aws Configはインベントリチェックもできる。
  • System Managerのインサイト機能、便利やな。
  • まとめ
    • マルチアカウント、マルチリージョンへの展開as a code
    • イベント集約管理も

14:00-14:40 【京王電鉄様ご登壇事例】AWS、Alexa を活用した情報システム部門クラウドシフトの進め方

  • ユーザー企業のシステム部は新技術というよりは、主業務に関わるシステムの最適化が求められていた。
    • 最近だと売上出せという傾向もある・・と。
    • 20年、30年とか使い続けるシステムもあったと。
  • Kintone, DataSpiderとか利用。

いいからAlexaの話はよ。(30分経過)
京王の情報システムのエンドポイントAPIと連携するLambdaファンクションってところかな。

  • Alexa 開発の落とし穴
    • 耳で聞いて声で操作。
    • 表現の幅が狭い
    • 作り手側による制御が困難
    • 完成後のギャップ大
  • 京王スキルでプッシュ通知開始!
  • ハイウェイバススキル
    • 呼び方とか大変だった。けっぱち とか呼ぶ場合もある。
  • まとめ
    • まずさわってみること、できることは自分たちでやってみる など・・
  • ユーザー企業向けまとめ
    • 今までみたことがない項目の明確な回答にベンダーは気を配って欲しい。
所感

Direct Connect上手に活用してるんだなー!
企業ってのは、人の人生を預かっているんだっていうことを、もう少し理解して欲しいよね。
SIerみたいな人売り商売だとそれは皆無だろうけど。

いろいろ聞いてみて思うのが、インプットを頭の片隅にでも必ず残しておいて、
それをアウトプットという形にできなくても業務で使う時にアウトプットとして残せれば、
その時に初めてセッションに参加してよかったって思えるんだろうなぁ。

15:00-15:40 ストリームデータ分析の AWS 設計パターン

  • 取込->変換->分析->アクション->保存
  • 拡張性、耐障害性、速度
  • マネージドサービス同士で接続を検討
    • 無理ならLambda関数で接続を検討
    • EC2上のアプリで接続を検討
  • まとめ
    • よりリアルタイムな世界へ
    • 動画や音声もストリームで
    • ストリームデータ ✖️ 機械学習
    • AWSのマネージドサービスを利用してシンプルに修正

16:00-16:40 AWS のリアルタイム処理入門

  • リアルタイム
    • エッジコンピューティング:greenglass
  • ニアリアルタイム
  • リアクティブ
    • リアクティブ宣言 reactive manifest, responsive(即応性), resilient(障害耐性), elastic(弾力性), message-driven(メッセージ駆動)
  • イベントソーシング
    • Lambdaのイベントソーシング
      • スケジュール処理から脱却しよう。
  • ステートマシン
    • AWS Step Functions

17:00-17:40 AWS のエッジネットワーク入門

すまねぇ、聞いたことのある話ばかりだった。

  • AWS Edgeサービス
    • CloudFront, Route53, WAF, Shield, Lambda@Edge
      • レスポンスの遅延、不安定なレスポンス、大量アクセスへの対応など
  • Lambda@Edge
    • エッジにおけるサーバーレスコンピューティング
    • CloudFront + Lambda = Lambda@Edge
    • Lambda@EdgeはNode.js
    • 世界中のロケーションにLambdaがレプリケーションされる。
  • Lambda@Edgeのユースケース
    • キャッシュヒット率の向上
    • コンテンツ生成
      • 画像リサイズ、HTMLページ生成
    • セキュリティ
      • トークンハッシュを使用した認証

18:00-18:45 Meet the builders ~ 社員が語る AWS とは ~

面白かった!開発はシアトル勤務・・。

  • AWSサービスは顧客ニーズの95%で出来ている。
  • DynamoDBを開発しているAWSエンジニアが語る Part1
    • 一つと言われたらOwnership model -> devopsのiterateが重要。作っているサービスを育てていく。大事にしていく。チームとして全て自分たちで出来る。逆に言うとなんでも出来る。デザインの時点で作り込んでいけることは、とても良いこと。やっていけばどんどんうまくなっていく。テストしたり運用に時間がかかると、リリースが遅れていく。どこに投資を出来るか、ということもチームで決めていく。テストしにくくなったらリファクタリングして育てていく、ということが重要。Single thread owner。Two pizza Team チームのサイズはピザ2枚分くらいがいい。チームとしてひとつのことを考えられ続けることができる力。一つのことを考え続け、どのように顧客側に貢献するかという夢を考える。MicroserviceのSingle threted Ownerとしてどのようにしていくのかを考える。
  • スピード感の維持について
    • 社内の組織の工夫。
    • 普段は組織なんだけど、緊急事態の時は、お客様の方に向くことが大事で、組織がフラットになることがすごい。
      • Amazonは地球上で最もお客様中心の考えになっている。
  • 今までの延長線上で考えるとダメだよってよく言われる話。
    • 常にチャレンジ。
  • DynamoDBを開発しているAWSエンジニアが語る Part2
    • 人がものをつくっていくという自覚。360度のフィードバックを活かしていくことができるというのが良い。イノベーションはやったことないことをやらないといけない。失敗した時に失敗するとおこられるじゃなくて、フィードバックとしてどうして失敗したのか、失敗してよかったのかなどを通して成長していけるカルチャーが素晴らしい。

19:00-19:40 【AWS Tech 再演】Amazon Redshift の 設計・運用大原則

  • 1.サイジングをちゃんとする
    • 設計段階である程度シェアなサイジングを行う
    • 初期容量のみでサイジングしない
    • 可能な場合は大きめのノードサイズを選択する
      • a.)容量ベースのサイジング、b.)性能ベースのサイジング
  • 2.Spectrumのアーキ原則をおさえる
    • パーティション、列志向ファイルフォーマットを活用する
    • データ量に応じたノードスライス数を用意する
    • データの持ち方を工夫する
  • 3.COPYの基本ルールを守る
    • 1コピーで複数ファイルを並列ロードする
    • 可能な場合は常にS3からロードする
    • 一意性制約の特性を理解する
    • エラーハンドリングを実装する
    • ロード時ありがちな問題
      • 一意性制約の行がロードされる
      • テーブルとファイル間の不一致
      • デリミター問題
  • 5.同時実行要件に正しく対処する
    • 実測する
    • 「現行システム要件」の実態を見極める
    • 本当に多数の同時実行クエリー数が必要な場合は、スロット細分化以外の方法を考える。
  • 6.クエリー特性を考慮する
    • スループット重視のバッチとレスポンス重視の対話クエリーはキューを分ける
    • 探索的クエリーなどのロングクエリー/ローグクエリーが想定される場合はクエリーモニタリングツールで予防線を張る
    • BIツールからの定型クエリーに対する備えをする
  • 7.VACUUMを工夫する
    • VACUUMを実行しないで済むように設計する
  • 8.更新処理を工夫する
  • クラスタ構成 -> ロード -> クエリ -> ハウスキーピング

全体所感

Day 3は諸事情により参加できなかっため、私はDay 2でおしまいです。
1日中、質の高いセッションを聞いていると、本当にいろんな人が私よりがんばってるんだと感じる。
だからこそ、同じくらいがんばらないとダメだと思える。仕事でもプライベートでも。
どれだけいろいろな人が高度で大変な仕事をしているのかという気持ちを、いつでも持っていたい。

2日目のお昼ごはん!量少ないのに満足できるなぜだろう。
f:id:yasay:20180614161220j:plain

参加した皆さん、お疲れ様でした!
以上で、AWS Summit 2018 Tokyoのレポートは終了です!

AWS Summit 2018 Tokyo 行ってきました!Day 1 レポート

今年も行ってきたよ!AWS Summit 2018 Tokyo!
www.awssummit.tokyo

↓飛天の間にそびえるAWSロゴの存在感!
f:id:yasay:20180613175228j:plain:w640

↓ちなみに、去年(2017)の飛天の間
f:id:yasay:20170604221009j:plain:w480


Tech系セッションは後ほど動画が公開されたらリンクを貼りたいと思います。
Day 1のレポートを書いていくよ!↓↓↓

Day1 5月30日(水)

8:30-9:00 アマゾン ウェブ サービス 12年のまとめ ~ Keynote をよりお楽しみいただくために ~

  • イノベーションのスピードが速い。
  • 顧客の要望を元に反映している取り組みが素晴らしい。
  • 日本のAWS Summitは世界と比較しても最大規模とのこと。
  • 世界で100万以上の顧客。日本では10万以上の顧客。少ない?多い?
  • AWSの歴史面白いなぁ。最初はS3から。
    • AWSが生まれた背景はモノリシックアーキテクチャからの脱却も理由の一つなのか。
    • 2枚のピザでお腹いっぱいにならないくらいのチームでマクロサービスを組織。"Two-pizza teams"
    • 初期はConsoleがなかった。
      • 2009年になって、初めてマネージメントコンソールができた。なるほど。
      • Kubernates環境作れるEKS使ってみたい。データサイエンティストって言葉便利だなぁ・・。
所感

AWSJ儲かってんな。
もう少しだけAWSの歴史を深堀りしてほしかったところ。
2006~2009年辺りのもっと濃い話が聞きたかったかなぁ。

10:00-11:30 Day 1 基調講演

  • AWS EDStart
    • 起業家と教育家を支援するためのAWSプログラム。
  • 大阪リージョン
    • ミッションクリティカルなサービスにおいて日本でディザスタリカバリをしたい要望のために生まれた
  • リージョンを結ぶ世界規模のネットワーク
  • クラウドの正しい概念設計を理解しよう
    • AWS Well-Architecture。基調講演でもこの話するのね。
      • 運用性、セキュリティ、信頼性、パフォーマンス、不要なコストの回避
      • ガイドラインとチェックリストとFAQ
      • パブリックに公開中!
  • クラウドエコノミクス(投資効果算定支援)
  • 人材育成
  • Center of Excellence
  • KDDI様セッション
    • 今後のAWSへの期待
      • 障害情報の迅速な連携
      • 大阪ローカルリージョンを正規リージョンへ
  • AWS MIGRATION ACCELERATION PROGRAM
    • ビジネスとテクノロジー両方の支援
    • 50:50で密接した関係で連携することで、初めてプロジェクトを成功に導くことができる。
    • 6つの視点に基づくアセスメントで、課題を洗い出して、最適なクラウドジャーニー計画。
  • 移行自動化へのアプローチ
    • SMS, DMS, Snowball
  • Amazon Elastic File System(新サービス)
    • NFSでアクセス可能な共有ファイルシステム
    • 割り当てられた容量にのみしか課金されない。(ネットワーク利用料とかなし)
    • 既存のLinux環境へのサポート
    • 伸縮性、スループット、スケーラビリティ
  • 大阪リージョンの背景
    • 東京リージョンとシンガポールリージョン利用による分散アプリケーションの構築、ではなくて、日本の中でやりたい。そのために生まれたのが大阪リージョン。
  • ソニー銀行様の事例
    • 地震・停電などのリスク要因を共有しない国内第二リージョンを要望。大阪リージョンになった。
    • 財務会計システム(総勘定元帳)でAWSを採用
  • 損保ホールディング様の事例
    • デジタルディスラプション
      • 保険からサービスに変わっていっている状況がある。保険はデジタルヘルスに統合される可能性。
      • イスラエルシンガポールにラボを作った。実サービス化したのは10件。42件は実証やトライアルなど。
      • 例:ドライブレコーダーを活用した安全運転支援サービス(DRIVING!)
    • AWSを選んだ理由
      • スピード、コスパ、スケーラビリティ、強固なセキュリティ
  • クラウドへ接続されるデバイスへの取り組み
    • AWS Greengrass
      • IoTデバイスの制御をエッジ側で行う。
    • FreeRTOS
      • Edge側で処理ができるように
所感

まぁ、なんだかんだ言って公式のプロフェッショナル派遣や、プロフェッショナル(エンタープライズ)サポートはすごいってこと。
これを個人の場合、受けられないので四苦八苦するしかないつらたん。でもたのたん。
大阪リージョン設立の背景に顧客要望をしっかりと受け止めようとするAWSの姿勢が見受けられる。

12:00-12:40 【 NTTドコモ様ご登壇事例】NTTドコモの AI エージェントを支える基盤の作り方

所感

コンピュータの進化によってトレンドになりえる昔からある技術が
他にもあるのだろうか。知りたい。
しかし・・・これはただの自慢話?タイトルと話の内容が合ってないような気がするぞ。
なんかとにかく偉そうだった辛い。それで、AI エージェントを支える基盤、どうやって作ったの??
AWS Summitの場で、SiriやAlexaより先に
音声アシスタントやってたんですよ的な強気発言、意味わからん。
とりあえずエンジニアに感謝しろって言いたくなるわ。

13:00-13:40 Alexa スキル ー ベストプラクティス

1.設計
  • 戦略的かつ想像的方向性の確率
  • 最も重要なアイテムは?
  • ユーザーフローの開発
  • 発生とレスポンスの準備
  • ポイント
  • 日々使うユースケースを考える。
    • 会話フローがシンプル・音声のほうが楽
    • コンテンツが最新
    • 特別な体験
    • 覚えやすいスキル呼び出し名
    • できることが明確
    • エラーがでない
2.開発
  • 新機能
    • 新しくなった開発者コンソール
    • AWS CLIAWS Cloud9で上級者開発
    • インテント履歴が見れるようになった
    • 新しい15種類のビルトイン・スロット
    • カスタムスロットに登録できる同義語(Synonyms)
  • アクセス権限
    • バイスアドレス
      • Alexa端末の住所を取得が可能
    • リスト
    • プッシュ通知(デベロッパープレビュー)
  • ダイアログモデル
  • 高品質な音声会話の提供(SSML)
  • breakタグ、phoneme、say-asタグ、audioタグ/効果音
  • キッズ向けのスキルが作れるように。
  • スキル公開でAWSプロモーションクレジットがもらえる
所感

知っている内容もあったけど知らない内容もあった。(ぉ
結果的に技術知識が向上したのでよかった。
作りかけのAlexaスキルさっさと作ろう。
スキルを公開するとTシャツがもらえるキャンペーン面白いな。

14:00-14:40 Dive Deep Alexa Voice Service

Cloud上に存在するAlexaが進化し続けることができる。これが評価を得ている。
ありとあらゆる製品にAlexaを導入し、Alexaと対話できるような環境を目指している。

  • 全体アーキテクチャ
  • ハードウェアアーキテクチャ
    • インターラクションモデル Close to Talk, Near-Field, Far-Field
    • Audio algorithms(音響エコー), マイクロフォンの数、マイクロフォンの配置の仕方
    • AVS 開発キット
  • プロトタイプから商用デバイス開発まで
所感

面白いなぁ。Raspberry Piで遊ぶか!

15:00-15:40 クラウド設計・運用のベストプラクティス集 “AWS Well-Architected Framework” を 100% 活用する方法

所感

立ち見だったからあまりメモ取れてない。
Well-Architectedの資料は日本語でも公開されているので、
読んでおくこと必須。→ 流し読み終わり
実際に運用するとなると、システム開発のフェーズ毎に
Well-Architectedを当てはめられるか確認していくことになると思うけど、
大きな企業の情報システム部なら既に似たような様式があると思うので、
Well-Architectedを活用して既存様式のアップデート検討もアリかな。
小さい会社でのクラウドネイティブ開発とかならすぐに適用してもよいと思う。
まぁ、全てを当てはめられるかは要相談。必ずしも当てはめる必要はないよね。

16:00-16:40 エッジデバイス上での機械学習の活用 〜エッジコンピューティングを支える AWS機械学習ソリューション〜

  • エッジコンピューティングとは
    • Cloudと異なる場所でコンピューティングリソースと意思決定機能を備える能力
  • 活用シーンは?
    • 自動運転、スマート農業、予兆保全などなど

エッジ側からトレーニングデータを送付、クラウドで学習して返却。
低レイテンシ、通信データの削減、オフライン動作などエッジ側のメリットはある。
しかしながら・・・

  • バイスのライフサイクルが長い場合、エッジデバイスが古くなり、HW/SW(OS)の更新を行うことが難しいケースがある。
  • 実施のハードウェアのスペックが低い場合もある。なのでクラウド連携した拡張があると良い。
  • エッジで完結させちゃうと推論結果の正しさを評価する仕組みがないよねー。
  • モデルは定期的に更新が入るので、エッジデバイス側に効率よく配信する仕組みが必要。
  • エッジ場での機械学習の活用進んでいる
  • 役割分担が重要
所感

やってみるしかない。
SageMaker使いたいなぁ。無料枠あるのかな。

17:00-17:40 AWS IoT の賢い利用の仕方とプログラミングの勘所

  • MQTTプログラミング
    • Pub/Sub, Broker
      • MQTTの場合はBrokerがいて仲介者がかならずはいる。なので、PubからBrokerが必ず受け取って、Subに送る。これがhttpとの大きな違い。Subscribeは常時接続。ニアリアルタイムの通信ができるので、早い。IoTに向いている。
    • QoS
      • IoT Coreで利用可能なQoSは"0"と"1"。QoS=2は利用できない。サンプルアプリもあるので、初期導入や動作確認で参考になる。MQTTをport443で利用できるようになった
  • IoT Core
    • shadow操作の基本
    • thing名の取得方法
    • shadowの状態に併せてルールを実行する方法

などなど、そのほかにも便利な組み込み関数が色々

  • まとめ
    • MQTT通信方式を理解し、設計・初期実装の時間を短縮
    • Iot Core, IoT Device Managementの機能を有効利用することで無駄な開発を避ける
    • 効率的なデータ配信にはtopicも重要
所感

上級者向けだった。むずたん。

18:00-18:40 AWS で実現する IoT 入門

予知保全ウェルネスの健康ソリューション、遠隔地からの患者のモニタリングなど

  • AWS IoT Device Management
  • AWS IoT Device Defender
  • AWS IoT Analytics
  • AWS IoT 1-Click

IoTデータのノイズ、ギャップのフィルタリング、処理、変換を実施

所感

すげーよく分かった。入門編だしね。ありがとうセッション。

19:00-19:40 【AWS Tech 再演】Amazon Aurora Under the Hood

  • キャッシュレイヤの分離
  • Aurora エンドポイント
  • Aurora ストレージ
  • セキュリティ
所感

去年受けたAurora Deep Diveと被っている箇所が多数。
しかしながら相変わらず上級者向けセッションなので必死についていく。
理解した気になった(ぉぃ

全体所感

1日中AWSの技術に浸かることができる至福の一日だった!
基本的に飛天の間のセッションを聞いていたので、パミールにあるEXPOブースとの往復がまさに地獄でした・・。
セッション間の休憩時間が15分しかないので、

  1. 3分でEXPOブースに到着w
  2. 5分間でEXPOブースや認定者ラウンジに行くww
  3. 3分で飛天の間に戻るw

というコミケ(?)のような所業。つらいので飛天の間に引きこもりがちにw
しかも初日は人の多さが半端なく、人酔いするほど!
人が多いせいか、セッションの時間進行もギリギリ。
基調講演ですら5分以上オーバーしてた。
そういえば今年はバンドのオープニングはなかったw

お昼ごはんは去年と同じカツサンド!おいしく頂きました!
f:id:yasay:20180613183228j:plain

参加した皆さん、お疲れ様でした!
Day 2 レポートに続きます!

以上です!