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 レポートに続きます!

以上です!

Virtual Box上の仮想マシンを快適に使うために設定した箇所

おそらく次のPCでもVirtual Boxの設定はカスタマイズすることになると思うので、
備忘録として残しておきます。

本エントリーは下記のPCスペックの設定例となります。

Windows OS Windows 10 Pro
CPU インテル® Core™ i7-6700HQ プロセッサー
メモリ 16GB (8GB×2 / デュアルチャネル)
メーカーHP http://www.mouse-jp.co.jp/m-book/mbk64/mb-k670xn-sh2_spec.html
Virtual Box Version 5.2.2 r119230 (Qt5.6.2)

システム

マザーボード

メモリは使えるだけ使う。
f:id:yasay:20180312190124p:plain

プロセッサ

プロセッサも使えるだけ使う!
f:id:yasay:20180312190225p:plain

アクセサレーション

準仮想化インターフェース:KVM
f:id:yasay:20180312190616p:plain

ディスプレイ

スクリーン

ビデオメモリー128MB
3Dアクセラレーション:有効化
ディプレイ関連の設定は変に弄ぶと逆にパフォーマンス下がったり(負荷が上がりすぎる)するので、
マシンスペックに応じたバランスが大事。
f:id:yasay:20180312190435p:plain

所感

自分は上記の設定でXubuntuを快適に利用しています!
xubuntu.org
さすがに標準フレーバー(Ubuntu)だと重くてつらたん。
もうWindowsだと辛い子になってしまったので、会社でもMacを支給してくれませんかね(ぉ

以上でした!

JJUG CCC 2018 Spring 行ってきました!レポート

今回は懇親会は不参加です。

http://www.java-users.jp/ccc2018spring/#/www.java-users.jp

セッション中に必死にコーディングしててレポートは少なめなんだ(´・ω・`)すまない
だから所感も含めて書いていくよ

レポート

10:00-10:45 JavaWebサービスを作り続けるための戦略と戦術

f:id:yasay:20180531214254j:plain

1.開発環境とCI戦略
  1. sh /.setup.shでミドルウェアは全部入る
  2. データベースもそれに含まれる
  3. AとBで干渉しないように
  • 当時、Docker for Macが不安定だったこともあり、Virtual Box + Dockerを利用。
  • Docker for MacだとPortとHostがmysqlとバッティングしたりもある。
    • 新人君が困るよね的な。
  • setup.shの内容
2.老朽化した技術からの脱却
  • Javaからtomcat.start()で起動できる。
    • Tomcatとは、インストールするものではなく、newするもの。
  • JasperReportはオワコン
    • flying-sourcer-pdfで作り直し
  • JSESSIONIDはオワコン
    • サブシステムをローカルで複数立ち上げた場合に、片方でしかログイン状態を保てない。エンジニアの生産低下
    • Tomcatでも変えられる。JavaConfigでも変えられる。
  • sticky-session-cookieもオワコン
    • 何が問題なのかと言うと、リリース後も片方系にアクセス集中したりする。
    • spring-session-redisのフィルタをかぶせるだけで、Redisにセッションを格納
3.フロントエンドと仲良くする
  • Swagger + SpringMVC大好評
    • @EnableSwagger2
4.手動テストも、自動テストも
  • テスト実行後にpushが大事。
    • プルリクごとにJenkinsが自動テスト
6.バージョンアップする
  • 銀の弾丸はない。
    • 金の弾丸はあるw
      • iMac Pro 136台wwwワロタwww
  • 目指す世界線は、誰でも環境構築できること。
所感

笑いを誘うセッション進行は本当に素晴らしい。話を聞いていて飽きない。
自然とこちらも笑いが込み上げてくる。
セッションの内容は参考になったが、既に私のプロジェクトで実践している点もあった。
とにかく今はVirtual Box + Vagrantによって仮想環境を持ち歩ける時代なので、
マイLinuxサーバーを常日頃利用することが多い。この利点は大きい。
これにより、CIも一人で回せる。一人で回して周りがいいと思ったらサーバーも立ち上げられる。
私の今の課題はもっとDockerを活用することなので、Vagrant環境でDockerをより使っていきたい。

11:00-11:45 Concourse CI入門 ライブ環境構築&ビルド

Concourse CI入門 ライブ環境構築&ビルド

所感

登壇者の方がConcourse CIの魅力と概要を語るセッション。
UIが次世代って感じでおらワクワクするぞ。
Docker composeで簡単に立ち上げられるので、個人で試す環境はすぐに作れそう。
プロジェクトの期間によってはCIははぶられることもあるが、
エンジニアとしてはいつでも準備できるようにしておいたほうがよいだろう。
登壇者の方はelmというaltJS押しでした。

11:45-13:30 普通の人のためのJavaコミュニティイベントのススメ

www.slideshare.net

所感

前回の2017 Fallの時もそうでしたが、ランチセッションはインプット重視の内容ではないので、
気軽に聞けて面白い。前回はJavaの歴史まで聞けて、初心者でなくても楽しめた。
今回の注目キーワードはDon't Be Shy。私もドントビーシャイになりたい。
初参加ではないのでランチはもらいませんでしたよ。今年もデューク弁当だったのかな?

13:30-14:15 Apache Tinkerpopとグラフデータベースの世界

www.slideshare.net

メモ
  • グラフ理論のグラフのこと
    • 不正検知、レコメンデーション/パーソナライズ、カスタマー360、マスターデータ管理
    • 用語的な:グラフ、バーテックス、エッジ、プロパティ
所感

Tinkerpopに興味があったからセッション見に行ってみました。
Gremlin言語を用いる。Tinkerpopはグラフ理論グラフのフレームワークという扱い。
概要は理解した感じ。日本の記事がググっても少ないのはお察し。
その中でも登壇者様の企業は異彩を放っていると思われる(思うだけ)。

14:30-15:15 Apache Kafkaとストリーム処理

speakerdeck.com

所感

そろそろ胃腸が働いていて眠くなる時間(ぉぃ
Apache Kafkaの概要は理解したぞ。
使う時がくれば、このスライドを思い出します。

15:45-16:30 古いフレームワークでもマイクロサービスアーキテクチャにしたい

docs.google.com

所感

古いフレームワークでもSpring Cloud ConfigとNetflix Eurekaを利用して恩恵を受けましょう的な話だったかと思うんですが、
すまない、Spring Cloud ConfigとNetflix Eurekaを利用するためのサーバー費用を上に相談するほうが
辛そうなんだが(´・ω・`)

16:45-17:30 REST APIに疲れたあなたへ贈るGraphQL 入門

www.slideshare.net

所感

さすがAWSJのソリューションアーキテクトを担当されているだけあって、
プレゼンの進行や話し方などしってかりしていてとても聞きやすい、見やすい。
内容としては「GraphQL概要理解したぜ!」、「Appsync使いたいぜ!」と自分の中で
盛り上がる内容だった。ここまでくるとAppsync使わない実装も調べたいんだぜ。
トレンド来るのいつですか?もう来てる?

17:45-18:30 DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話

www.slideshare.net

所感

最初のレガシーシステム構成つらたんな状況から、
さっとDDDとクリーンアーキテクチャによる実装例を紹介してて、
サーバーたくさんあってむしろマイクロサービス+DDD+クリーンアーキテクチャじゃねって
感じでわくてかしながら見てました。
笑いを誘う進行も楽しく、見てよかったと感じました。

全体所感

今年も楽しませてもらいました。ありがとうございました。
またFallにお会いしましょう。(Winterか?)
f:id:yasay:20180531222857j:plain

(小ネタ)Spring Bootを2.0にアップグレードする時のGradle Wrapperのアップグレード手順

本エントリーは下記環境で検証しています。

移行元Java バージョン 1.8
移行元Spring Boot バージョン 1.5.2
移行先Java バージョン 9
移行先Spring Boot バージョン 2.0.1

私が学習用に用意しているリポジトリはまだ大したことはしていない(ぉぃ)ので、
Spring Bootを2.0にアップグレードする際は、Gradleのバージョンを上げて、
build.gradleを修正するだけで対応できました。

./gradlew wrapper --gradle-version=4.5.1


変更差分はこちら↓
https://github.com/x-blood/xblood-spring-boot/commit/8addb65dcce53056f7ef04191b171fe9407b9e5a#diff-c197962302397baf3a4cc36463dce5eagithub.com

これからも上記のような作業は定期的に発生しそうなので、備忘録としてエントリーを残しました。
最近業務でもSpring Bootを使う機会があり、ノウハウが増えていい経験になっていると思います。

## 参考資料
Gradleを使ってビルドしているSpring BootのアプリケーションをJava9に移行してみた話 | Developers.IO