今年も来ました。

去年は目黒のAWSオフィスで3日間でしたが、今年は神田明神ホールで2日間になっています。

https://aws.amazon.com/jp/about-aws/events/2019/devday/

• AWSグローバルで開催する開発者のためのトレーニングイベント
• 最新のテクノロジー、開発手法などを集中的に学ぶことができる場
• セッション公募を行い、11件採択された

10:00～11:40 ゼネラルセッション

＠岡嵜 禎

• AWSではBuilderという言葉を大事にしている
  • 開発者
• amazon go 北米ではすでに10店舗以上展開
  • 多数センサーからのリアルタイムデータをリアルタイムで処理できている
• Prime Air
  • 5万モデル検証、1万機作成して検証
• Project Kuiper
• 様々な場面と用途で使われる機械学習
  • AIサービス、MLサービス、フレームワーク＆インフラストラクチャのレイヤ
    • 利用者のレベルによって使い分けられる
• Well-Architected Framework
  • ホワイトペーパーとツールを提供
  • ツールは9月に日本語版リリース
• On Builders and Dreamers
  • ジェフベゾスの言葉

＠まつもと ゆきひろ

• プロ・プログラミング技術者
• 20世紀の言語
  • インターネットとともに
  • Ruby, JS,
• 2000年代
  • 手軽、柔軟、生産的、楽しい
• 2010年代
  • 関数型、手堅い
  • ブロック、型推論、少ないお約束
  • 企業によるスポンサー
    • Go, Swift, Rust, TypeScript
• どの言語を選ぶか？
  • 評価基準を持つこと
  • 生産性（効率、コスト）
  • 唯一の解はない
    • 背景によって異なる
  • 判断を人に任せない
  • 風をおこし、強める

＠倉貫 義人

• SIerの受託開発の中でアジャイルをやるのは難しい
• そもそもアジャイルがマッチする案件なのか（制約条件）
• 納品のない受託開発
  • 月額定額
  • 見積り、要件定義（ビジネス上の制約）しない
  • クラウド、OSSのおかげで一人でできることが増えた
• Software is eaticg the world
• ソフトウェア開発の本質 　- 大量生産、ルーチンワーク、製造業ではない
  • デザイン、問題解決。ナレッジワークであt
  • プログラミングを手段に、問題解決する仕事
• これから求められる仕事とは
  • 人類の文明の進化は不自由を置き換えてきた
  • 自由な発送が求められる、好きで楽しめるか
  • クリエイティブな仕事、人数のいらない仕事
• この先のエンジニアの生き方
  • ソフトウェア開発の仕事は、減ることはない
  • 腕を磨き続ければ、自分の価値を高められる
    • 人がいなければ、企業は成り立たない
  • あなたの仕事は、難しいからこそ価値がある

トークセッション

• 令和の時代。更に輝くエンジニアになるために必要なこととは
• これまでのキャリアはどのようにして築いてきましたか？
  • まつもと）東京は嫌だったので浜松に就職した。会社が傾いて閑職に置かれてRubyを作り始めた。
  • 倉貫）社内SNSを作ったところから。JavaではなくRoRを選んだ。
• AIがプログラムを書いてくれる時代になったときのプログラマーの存在価値はどうなるか？それでも必要とされるプログラマーとなるために求められることは？
  • まつもと）問題の定義
  • 倉貫）プログラムのデザイン自体クリエイティブな部分、AIが出てきても書けば良い。
• どんな人と一緒に働きたいか
  • まつもと・倉貫）主体性のあるプログラマ
• 自分のスキルアップ
  • まつもと）海外のブログとか見る、得意なところから周辺に広げていく、自分の中にインデックスを作る
  • 倉貫）得意があるメンバーでチームを組む

12:00～12:45 第1回 AWS Fargate かんたんデプロイ選手権

• Fargateとは
  • AWSマネージド
  • コンテナネイティブ
  • AWSサービスとの連携
• ECS on EC2の運用
  • OSやエージェント類へのパッチあて、更新
  • インスタンスのスケーリング
  • コンテナとホスト2重に対応
• Fargate CLI
  • サービスを削除するときはスケールインしてからデストロイ
  • ターナー社がforkしたものもある。インタフェースが異なる。
  • pros
    • vervose オプションで自動生成されるリソースの勉強ができる
    • とにかく簡単
  • cons
    • 本番環境で使うにはちょっとアドホック
      • Fargate CLIのバージョンアップで変わるところがあるかも
    • CI/CDと合わせて構築するには考えないと
• nathanpeck/awesome-ecs
• なぜこんなにたくさんあるのか
  • サービスリリース時には最小限（MVP）なもの
  • リリース後にユーザーからのフィードバックで成長させる
  • 利用者がそれぞれ作るので多くなる

13:00～13:45 マルチテナント時代におけるテスト・ベストプラクティス

場所どり失敗してスクリーン見えなかったのでログなし。

14:00～14:45 5G時代を見据えた、IoTプラットフォームSORACOMのアーキテクチャへの挑戦

• SORACOMプラットフォームを支える技術
  • Polaris
  • Dipper
  • Hubble
• MNOとAWSのをDirectConnectで接続
• AWS上に構築する利点
  • スケールが容易
  • アップデートも容易
  • 複数AZで高可用化
  • Queueでバッファリング
  • DynamoDB Streams
• API Centricかつmicroservicesな設計
• リリースサイクルは2週間（1イテレーション）
• 開発者は全員運用にも責任を持つ（DevOps)
• 運用のための開発（OpsDev） -監視効率化、繰り返し作業の自動化
• andonのアプローチ
  • 不具合かも？と思ったことを書き込むSlack channelがある
• Private LTE
  • 実験段階
  • 地下とか通常の電波が届いていないところに
• 広帯域、低遅延によるリッチなユーザー体験
• 5Gコアネットワーク
  • 通信プロトコルが少なくなり、HTTP/2になる？
  • ステートレス
• ネットワークスライス
  • 回線の用途に合わせて、ネットワークを仮想的に分割する

15:00～15:45 AWSの「隙間」を埋める隙間家具OSS開発

• AWSはコア機能以外は後回しにすることが多々ある
• その、工夫でなんとかなるような部分を「隙間」と呼ぶ
• 実例：S3とRedshiftの間
  • S3からRedshiftにデータを取り込むためにCOPYコマンドが必要
    • S3イベント通知でSQSに送信、SQSメッセージをもとにRedshiftにCOPYを発行
• Rinの教訓
  • どう考えてもマネージドになってほしいものはその内なる（いつか）
  • 複数のサービス関連系を一度に処理するとリトライが複雑になる
  • 単機能に特化しつつ、そのドメインでの汎用性をもたせると使い回せる
  • マネージドになったときにきれいに取り外せる設計大事
• 事例：S3 to CloudSearch
  • CloudSearchに継続的にデー0田を取り込む手段がない（ElastiSearchはFirehoseが対応している）
  • S3に配置したJSONをLambdaでCloudSearchにHTTP POSTする
• s32csの教訓
  • cron処理ではなくデータのイベントドリブンではないのか？
  • 状態はマネジ度サービスに、状態を持たない処理だけ書くとスケールが容易になる
• 事例：ssmwrap
  • SSM Parameter Storeの値を環境変数に設定してコマンドをexecするwrapper
• そのうち取り外すものをなぜわざわざ作るのか
  • アプリケーションで直接書くと密結合する
  • 取り外したいときに密結合していると改修しづらい
  • ライブラリに切り出されていないとコピペされがち
• OSSとして作る理由
  • ドキュメントを書く気になる
  • 過度な社内事情の混入を防ぐ
    • 設計がきれいになる
  • 魔改造版が増殖するのを防ぐ
  • 独立したパッケージになっていないとコピペされる
  • コピペ後に改造されると新機能やバグフィックスに追従できない

16:00〜16:45 マルチリージョン・マルチアカウント対応の柔軟な構築ツールを作ってみた

立ち見だったのでメモなし。 CFnのTipsは資料公開されたら確認したい。

17:00〜17:45 AWSをフル活用したコネクテッドカーを支えるアプリケーションの開発・運用・監視術

• Connected Autonomous Sharing EV + MaaS
• フリートオペレーションサービス mobi-Crews
  • 車載端末からクラウドにデータを送り、リアルタイムに管理者が確認できる
  • 運転状況で安全指導にも
  • RoR+Docker
• プロダクトの課題と解決方法
  • 性能
    • 負荷の分割
  • セキュリティ
    • 外部機関と連携して定期的に評価
  • その他非機能要件
  • →開発、検証、運用に強いメンバを集める

感想

• IaCはもう当たり前になってきている
• IaCを実現する手段は混沌としている
• Serverlessへの流れは大きくなっている
• まつもと氏のスライドに使っていたRabbitというのが気になった（ウサギとカメでタイムマネジメントできる） 　- https://rabbit-shocker.org/ja/