AWS DevDay Tokyo 2019 - Day 1 セミナーメモ

AWS DevDay Tokyo 2019 - Day 1

2019/10/3 ~　10/4

1日目（10/3）：午前中はジェネラルセッションとしてAWSの技術統括本部長とまつもとゆきひろ氏、倉貫 義人 氏の3名で「今後のエンジニアに必要な事」のお話し。

午後からは個別セッション。ハンズオンでAmplifyのメリットを体感できたのは面白かった。

General Sessioon

AWS Message

• Sperker:岡嵜 禎氏（アマゾン ウェブ サービス ジャパン株式会社 執行役員 技術統括本部長）

• Builder:新しいものを切り開いていく人たち

  • 新たな道を切り開いていく可能性に満ちた現状
    • RE:MARS
    • amazon go
      • 商品にタグをつけるのではなく、画像処理、センサー処理をリアルタイムで行い、機械学習などを用いることで実現
    • Amazon PrimeAir
      • 今年度中に実用化：最新モデルは5万通りのモデリングをコンピューティングで試行し、1万機を試作したうえで最適なモデルから構築
        • 安全性：コンピュータビジョンで鳥などの存在、着陸時の人、障害物の存在を認識し安全か判断し行動
    • Project Kuiper:地球低軌道の衛星との通信のためのコネクションを
  • イノベーションに巨額な投資は不要
    • イノベーションを実現できる
    • 自由を得ることができる
    • PDCAサイクルを迅速に回すことができる
  • 様々なテクノロジーを簡単に速く実現できるPlatformを提供

• 現状最重要：機械学習

  • 様々な領域で適用可能
    • コンピュータビジョンやリコメンデーション、自然言語処理など
  • AWSサービス：すべての開発者に機械学習を
    • AIサービス、MLサービス、フレームワーク＆インフラストラクチャの各層でサービス提供

• モダンアプリケーション

  • 目的
    • 市場投入を加速
    • イノベーション向上
    • 信頼性向上
    • コスト削減
  • 実際
    • オペレーション
      • 価値を生まない作業をオフロードしすべてを自動化
    • アーキテクチャ
      • マイクロサービス、疎結合、イベントドリブン
    • Developer－Firstな開発フロー
      • CI/CD－すべてを自動化
    • セキュリティ
      • 自動化されたセキュリティ評価
      • 適切なアクセス権限、成果物の検証
    • データ
      • 正しいツール、目的に適したDBの利用による生産性の向上
  • アプリケーション実行環境の広がり
    • EC2
    • Container
      • Fargate
      • EKS
      • ECS
    • Serverless
      • Lambda
  • Opsが不要であればよりNoOpsなサービスを利用可能に
  • Well-Architected Framework
    • ホワイトペーパー
    • Well-Architected Tool

• On Builder and Dreamers

Sperker:まつもとゆきひろ氏

• Ruby:1995年公開：20世紀の言語
  • Java,PHP,JavaScriptなども同じ年
  • インターネットの普及に伴い、必要とされる言語が変わってきたタイミングだった
  • 2000年代の動的言語
    • 手軽、柔軟、生産的、楽しい
• 2010年代のトレンド
  • 関数型、静的型、手堅い
  • 見かけが動的っぽい
    • Swiftなど
    • Rubyのブロック類似
    • 型推論
    • 少ないお約束
  • 企業によるスポンサー
    • GO-Google
    • Swift-Apple
    • Rust-Mozzilla
    • TypeScript-Microsoft
• どの言語を選ぶか？、どのテクノロジーを選ぶか？
  • どのような評価基準で選ぶべきか？
    • 生産性ーいかに効率よく開発できるか、開発上のコストベネフィットがいかに得られるか
    • 唯一の解はないー背景によって異なる
      • すべてのことにはトレードオフが伴う：この点はこちら、あの点はあちら。。。
        • トレードオフをどれを選ぶか、どう判断するか
      • 動的言語は生産的ー場合によっては真だが、制約条件によっては偽
    • 自分のプロジェクトはどのような制約条件があり、それは変えられるのか？などの背景を考慮
• Big Sites Use Ruby
  • Cookpad
  • gitHub
  • Airbnb
  • TreasureData
    • Big SiteでRubyを使ってもOK
  • Rubyをさらに良くする：CookpadはフルタイムのRubyコミッタを2人抱えている
    • GitHubも自らの問題を解決するためにRubyを改善するコミッタを持つ
• 判断を人に任せない
  • 技術の選択時、自分が生産性になれるかを、実際にソフトウェアを作らない人（役員とかマネージャーとか）に任せない
    • そのような判断を誰かに任せずに、自分で判断できる環境に身を置く
    • 技術者を大事にしない組織もたくさんある
      • そんな会社は辞めたらいいと思う
  • Tumble Weed-風に吹きまわされる
    • 自分の基準を持って風を選ぶ
    • 自分の望む方向に行くような風を強める
    • 最終的には自らが風を作る
      • ＝主体性
      • コントロール意識：事態が自分のコントロール下にあると思うとストレスが下がる：逆だと生産性が60%下がる

Speaker:倉貫義人氏（株式会社ソニックガーデン）

• キャリアのはじめ：TIS：SIer
  • プログラマーが楽しくなさそうに働いている
    • 社内でアジャイル開発の普及活動
      • 受託開発では難しい：結局一括請負で納品は最後1回だけ
        • →社内システム
        • →社内ベンチャー
      • そもそもほんとにアジャイル開発があっているのか／○○をやりたい、と言っているけど、ほんとにそれはあっているのか？
        • 大事なのは背景やビジネス、やらねばいけないこと、制約条件に合わせて選ぶべき
          • 例えば一括請負の受託開発でアジャイルは無理→アジャイル開発が向いている制約条件を作る
            • 納品のない受託開発をビジネス化：月額定額ビジネス
              • 見積、要件定義なし、ドキュメントなし、プロジェクトなし、契約時間なし
                • 要件定義はSIerがお客様ともめないためにしっかり作ろう、という類のものなのでは？
                • プロジェクト：ほんとに人たくさんいる？：まず一人でできる量でやる：クラウドやOSSが広がったおかげで一人でできる範囲が広がった
• Software is eating the world
  • ソフトウェア開発の本質とは？
    • 大量生産、ルーチンワーク、製造業ではない
    • デザイン、問題解決、ナレッジワークである
    • プログラミングを手段に、問題解決をする仕事
  • これから求められる仕事とは
    • 人類の文明の進化は不自由を置き換えてきた
      • 人がやると大変なことを置き換える
    • 自由な発想が求められる、好きで楽しめるか
      • 不自由がなくなるとどんどん自由になる＝最終的には自由で、好きなことをできる
    • クリエイティブな仕事、人数のいらない仕事
  • この先のエンジニアの生き方
    • ソフトウェア開発の仕事は減ることはない
    • 腕を磨き続ければ、自分の価値を高められる
      • 会社のバランスシートに反映される価値としてではなく、自分の価値として得られる
      • 会社に残るのではなく、個人に残るのがスキル：どんな資産があろうとも、スキルを持った個人がいなければ会社として成り立たない
    • あなたの仕事は難しいからこそ価値がある

トークセッション：令和の時代。さらに輝くエンジニアであるために必要なこととは

• これまでのキャリアの築き方
  • まつもと氏：独立系ソフトウェアハウスで自社システム構築
    • 閑職の中でRubyを作り始める→だんだんRubyにシフト→全部Rubyに
      • Rubyの言語開発は趣味
        • 様々な領域に触れる：面白がりながら作ってた
  • 倉貫氏:大手SIerから独立→社内SNSを作り、それを外販
    • 閑職に追いやられて、社内システムを作成、こっそりローンチ：ミクシーが流行っていた当時
      • 閑職で腐らずにいかに好きなことをやるか
    • 判断のとき、マイノリティのほうを選ぶ：少ないほうが目立つ、役立つ
• AIがプログラムを書いてくれるようになったら、プログラマーの存在価値はどうなる？今後のプログラマーに求められる知識、能力とは？
  • まつもと氏:AIが仮にプログラムできるようになっても、設計、システムに何を求めているかはAIにはできない：結局その定義の必要性は普遍的なのではないか？
  • 倉貫氏:現在のコード補完の延長線上？→プログラムをデザインするとかは残るし、そういったクリエイティブな部分が楽しい
    • AIがプログラムを書いても、今まで通り人がプログラム書いてもいい
  • 優秀なエンジニアとは？
    • まつもと氏:主体性がある人、私はこうしたいと言ってくれる人
    • 倉貫氏:受託脳（いわれたことをやる）＝誰かが言わなければ何もできない＝自分の頭で考えることが重要
  • 主体性を育てるには？
    • まつもと氏:主体性を壊す環境はたくさんある
      • 悪い環境・会社は淘汰されるべき
    • 倉貫氏:管理しない会社：「うちは管理しないと働かない」と他の経営者に言われる：ほんとに？管理しすぎるから管理されないと動けなくなる
      • 会社と社員は従属関係ではなく、対等な関係
      • 会社を変えるって難しい：自分で会社を選ぶ
  • 新しい技術を学ぶ手段・スキルアップ手法は？
    • まつもと氏:海外の技術ニュース
      • 自分の得意なところから伸ばす
      • 自分の中でインデックスを作る：これは誰に聞けばわかる、とか
      • 生産性を高めるのは自分が楽になるため：バッファを積む
    • 倉貫氏:技術分野はすごく広がっている
      • チームで解決しよう＝この人は何が得意
      • ソフトウェア自体は一人でできるが、わからないときに立ち止まってしまう：チームはその解決のため
      • 人月でビジネスしない：人月でのビジネスをプログラマにさせるのがすべての元凶：バッファをこっそり積むとか
      • 仕事を時間で管理しない：早く終わったら仕事がまた来るっていうのはきつい：成果がでたら早く終われば後は自分の時間
• 今後の注目技術
  • まつもと氏:Lambda等のサーバレス
  • 倉貫氏:機械学習：浅いレイヤーで機械学習が使えるようになるのはすごくいいこと：エンジニアが今まで手に届かなかったところに届くようになったのがクラウド
• メッセージ
  • 倉貫氏:自分の人生をどう幸せにできるのか：セルフマネジメントをできる領域をどれだけ増やせるか：エンジニアはスキルを磨くことでそれができる
  • まつもと氏:自分のコントロール意識を増し、裁量を増やし、自分で判断する。他人は自分の幸せを保証してくれない

.NET開発者がいまさらはじめるクラウド戦略

• Speaker:森　博之氏

• 環境の変化と文化の変化

  • クラウド化の動機
    • 新サービス構築
    • システム・インフラの老朽化、サポート終了による移行
      • 選択肢：Retire,Rehost,Refactor,Rearchitect,Rebuild,Replace
  • Windows環境の変化
    • Windows開発にはC/C++とMFCやATLのライブラリ：Visual Basicでのアプリ開発
    • →.NET Frameworkへ：メモリ管理、セキュリティ、バージョン管理：様々な言語が混在できるようになった
    • →ASP.NET Web FormsモデルからMVCへ：アクセシブルなHTML/CSSレンダリング：モダンなフロントエンドやMVCの開発手法を取り入れやすくなった
  • Culture change
    • 成功している企業でおこっていること
      • 成功のベースとなったアイデアやコンセプト
      • 成長させるために加えた機能
      • それによって暗黙的に成長した文化
    • 永久マシンのようなビジネスの仕組みはない
    • InnovationとModernization
      • 新しい概念やコンセプト、従来あった技術をモダナイズ

• 注目したいテクノロジ

  • .NET Core
    • クロスプラットフォーム
    • オープンソース
    • フレキシブルなデプロイ方式
      • Framework-Dependent Deploy
      • Self-Contained Deploy
    • Modular
      • 小さなアセンブリパッケージで構成
        • .NET Framework全体ではなく、必要な部分だけ取り出して構成可能
      • NuGetを通じてリリース
      • 必要なパッケージのみ取り込む
    • ASP.NET Core
      • Startupクラス
      • DIフレームワーク
      • ミドルウェア
      • Hostのビルド
      • HTTPサーバ（Kestrel)の実装
      • Configurationプロバイダー
      • Optionパターン
      • IHostingEnvironment
      • ILogger
      • Routing
    • .NET Core 3.0
      • gRPC
      • Worker Service
      • Web API
      • Blazer
        • .NET（C#)でインタラクティブなUIを構築するためのフレームワーク
          • C#のプログラミングでUI構築
        • Server-SideとClient-Sideの2つのホスティングモデル
          • Server-Sideのほうが推奨
          • Signal-Rを用いたサーバからクライアントへの技術
    • .NET マイルストーン
      • .NET Core 3.1 LTS:2019/11
      • .NET 5: 2020/11
  • Serverless
    • .NET Core CLI
      • Lambda用テンプレートの導入
      • AWS Extentions for .NET Core CLI
  • Container
    • Docker Windows Containers

• DEMO:GitHubで公開

  • hiroyukimori/awsdevday2019

DynamoDBによるアプリ開発

• Speaker:成田　俊氏（アマゾン ウェブ サービス ジャパン株式会社）

• Intoroduction

  • フルマネージド、ハイパフォーマンス、エンタープライズ対応
    • メンテナンスフリー、サーバレス、スループット無制限
    • You build it, you run it.
  • メンテナンスフリー
    • セキュリティ、耐久性、可用性、性能、拡張性を気にせずに開発できるのは大きなメリット
  • Table構造
    • Itemsでデータを分けて保存（行に相当)
    • Items内にAttributesを持つ（カラムに相当）
    • Partition Key：必須　Key-value access patternを決定
    • Sort Key：
  • NoSQL Workbench for Amazon DynamoDB(Preview)
    • Data modeler
    • operation builder
    • 等をGUIで管理、操作可能な機能

• サンプルアプリ解説

  • API Gateway -> lambda -> DynamoDB
    • Chaliceを使って構築
  • DynamoDBの特性
    • カーディナリティが低いAttributeをPKにすると、書き込みが増えてきたときにスロットリングに引っかかり遅くなる可能性あり

• CIをどうするか

  • 並列実行したときに同じデータを扱う可能性あり
    • Table名をビルドプロジェクトごとに分ける：並列実行BUildが少なければ問題なし→多いと制限に引っかかる可能性
  • DynamoDB Localというローカルで実行可能版が提供されている
    • ローカル開発はそちらで、リリース前に本番DynamoDBで
    • 対象アプリケーションと同一コンテナにDynamoDB Localを同居させる形と、別コンテナで実行する形の両方あり
    • DynamoDB LocalはJarでの提供 or AmazonオフィシャルのDynamoDB Localコンテナイメージもあり

• まとめ

  • データモデリング、Item操作の記述に迷ったら：NoSQL Workbench for Amazon DynamoDBでテストを
  • DynamoDB Streamsなどほかのコンポーネントとの組み合わせで