二日目（最終日）です。

今日もサーバーレス系中心に見ていきたいと思います。

10:00〜10:45 オープンソースコミュニティで加速するサーバーレスの未来

• クラウドの世界の中にいながら、オープンソースコミュニティに参加することの意味と楽しさ
• Lambdaの問題（当時）
  • マネコンにソースを直接アップロードするのでバージョン管理どうする
  • CI/CDどうする
• それを解決できるServerless Frameworkの登場
• Serverless Setp Functions
• OSS活動を継続的に続けるモチベーション
  • スキルのあるプログラマからのレビューを受けられる。スキルアップできる。
  • 遠くの国のあったことのない人から感謝される喜び
  • 自分の書いたコードがたとえ1行だとしても世界中の人に使われて、どこかの誰かの役に立っているかもしれない
• OSS活動を継続させるには
  • 誰からも反応なく飽きてしまう、地味
  • スターが1000以上、関わっている人が複数いる、help-wantedタグがついているissueがあるプロジェクトに継続的にプルリクを送り続ける
  • 先送りにされている問題を潰していく人の存在は重要
  • プルリクを出し続けたプロダクトのプラグインなど付随のOSSを出してみる
• オープンソースの未来とサーバーレス
  • Cloud2.0
    • 究極のサバーレスアプリケーションには全くコードがない
    • サーバーレスの狙いはよりコードを少なくクラウドのサービスをできる限り使うこと
    • フルマネージドサービスをうまく利用することで責務の多くをクラウドに任せ、ビジネスバリューを出すための仕事に集中すること
  • Cloud2.0の時代でも、コードを書くということが本質的になくなっていくことはない
  • 新しいものが出るということは新たな問題も発生するということ。問題とはチャンスであるということ。

11:00〜11:45 Chaos Engineering ～入門と実例～

Chaos Engineering の進化と今

• 障害を避ける最も良い方法は継続的に障害を起こさせること（Netflix TechBlog 2010.12.16）
  • Chaos Monkey: インスタンスをランダムに停止
• Failure Injection Testiong(2014.10)
• Chaos Monkey, Simian Arm
  • 影響範囲の限定が難しい
• Chaos Kong(2015.9)
• PRINCIPLES OF CHAOS ENGINEEERING
  • カオスエンジニアリングとは、「対象とするシステムが本願環境における不安定な状況を耐えることができる」という自信を構築するために当該システムにおいて実施する
• ChAP: CHaos Automation Platform(2017.7)
• Aitomaiong chaos experiments in production(2019.5)
• Gremlin Inc
  • 仕組みやツールを提供する企業
• ChaosTOolkit
  • OSS
• Chaos Testに取り組むなら、最低限の可用性設計はできていることが望ましい。

後半

• Chaosconf振り返り
• Our 4 Setp Aproach
  • 定常状態
  • 仮説設定
  • 故障発生
  • 仮説反証
• Our Next Aproach
  • 影響の最小化

12:00〜12:45 よくある課題を一気に解説　御社の技術レベルがアップする 2019 秋期講習

• コンテナのCI/CDちゃんとしたい

  • CI/CDはアプリケーション開発を効率化する仕組みや開発手法のことで、単一の技術を指すものではない
  • 手作業でのデプロイと決別する
  • リビジョンとデプロイメントを連動させることを考える
  • マネージドサービスを中心にパイプラインを構成する

• ログ設計どうすればいい

  • ログの種類と目的を考える
    • アプリログ、ミドルウェアログ、OSログ
    • 用途にあったものが出力されているか確認する
  • ログの設計をする
    • ログレベル
    • 出力先
      • 運用者がすぐに見つけられるところに集約
    • 権限
      • 適切なログの権限あのか。見れる・見れない、変更できるできない
  • アプリケーションにあったフォーマットを考える
    • デフォルトでは出力されない項目もある

• いい感じの機械学習基盤を作りたい

  • できる限りマネージドサービスを使えないか考えよう
    • 自分でモデルを作らなくても学習済みのモデルをAPIで簡単に使える（AIサービス）
    • サービスの利用SageMaker（MLサービス）
    • フレームワーク＆プラットフォーム
  • どこまで自由度を求めるか考えよう
    • データだけ準備（AutoML、SageMaker）
    • モデルも自分で書く（SageMaker）
    • コンテナ持ち込み（SageMaker）
  • ワークフローの構築と自動化を考えよう
    • StepFunctions

• セキュリティ自動化

  • セキュリティ要件なサービス運営者自身から出てくるもの
    • 何をすべきかは各社、各ビジネスによって異なる
  • まずマネージドサービスを使おう
    • 自分の責任範囲を小さくする（責任共有モデル）
    • セキュリティ系マネージドサビスで低コストに高機能を得る
  • キャッチすべきアラートやイベントを決めよう
    • 何を検知できるのか、発生時にどう影響があるのか
  • イベントに対するレスポンスを考えよう
    • Lambda, StepFunction

13:00〜13:45 Serverless Elixir with AWS Lambda

• よく使われるマネージドサービス
  • Lambda, API Gateway, DynamoDB, ALB
• 長所
  • サーバー運用費用が安い
  • 運用オペレーションが不要
  • 自動スケールでトラフィックスパイクに強い
• 短所
  • デプロイメントが複雑
    • ローカルとの差分、テスト
  • 対応ライブラリが少ない
    • Railsとか
  • データベースによる制約
    • 高トラフィック時のコネクション数上限
  • 様々な制約
    • 関数の同時実行数
    • 関数の最大処理時間/タイムアウト時間
• Lambdaのアーキテクチャ
  • Firecrackerベース
• Custom Runtime
  • Lumbdaで任意の言語のランタイムを実行させる機能
  • 実行に必要なもの
    • bootstrap: Lambda起動時に実行される
    • handler: 呼び出しごとに実行される
  • Elixir
    • ErlangVM上で動作する
    • 並行プログラミングしやすい
  • bootstrapでErlangVMを起動する
• Serverless Elixorアプリの運用
  • デプロイ
    • CFn
    • Serverles Framework
    • SAM
  • 利用するツール
    • DOcker
      • AmazonLinuxイメージを使って動作確認することでLambdaと同じ動きになる
    • mix(Elixir標準のTaskRunner)
    • CFn

14:00〜14:45 Nature Remoの裏側 ~ AWSとWeb技術をIoTの世界でフル活用する

• 2年で10万台突破
• Remo E
  • スマートエネルギーハブ
  • ECHONET Liteプロトコルを利用
    • スマートメータとHEMSを綱不標準プロロコル
  • スマートメーターやソーラーパネルｍ蓄電池の操作や情報収集
• UDPホールパンチング
• ecspresso
  • ecs-deployから乗り換え
  • 既存のタスク定義を利用できる
• Consul
  • CloudMapに乗り換えていきたい
• Log
  • zap で CloudWatch Logs に送信→高い
  • firehoseでS3に直接
• IoT,MLサービス
  • 無理して使う必要はないが、引き出しを広げておきたい
• 内容は、golang.tokyo#26とほぼ同じだった。

15:00〜15:45 DRIVE CHARTにおけるSagemaker migration

• DRIVER CHART
  • AIを活用した交通事故削減サービス
  • 昨日のデンソーの発表であったものに近い？
• 車間距離
  • 概ね検出できるではなく、制度が求められる
  • Networkの調整
• Sagemakerの用途
  • セキュアなjupyterとして便利
• 学習コストを下げるため、us-east-1を使っている
• 課題
  • EC2の管理が必要
  • 落とし忘れ
  • セキュリティ対応
• SageMaker後
  • インスタンス管理不要
  • 学習終了すればコンテナが終了するので落とし忘れなし
• magnaged sopt training
  • checkpointをS3に取ることで、spotインスタンスが落ちたときにも再開できるようにする
  • 再開処理は自分で実装する必要がある
• local mode
  • 起動が早いので、デバッグに向いている
  • 通常5分くらい起動にかかる
  • 未対応の処理もある
• 上限
  • 実行時間、インスタンス数
  • 緩和申請で引き上げられる

16:00〜16:45 レガシーコードからの脱却

• レガシーコードとは
  • テストのないコード
  • 保守または拡張が困難なコード
  • 理由は問わず修正、拡張、作業が難しいコード
• 同じ用語を使っていても、中身の認識に相違が出ることが多い
• 使われるソフトウェアは変更が必要になる（成長）
  • 必要な変更をすべて予測するのは無理
  • 変更可能となるように書くべき
• ソフトウェアの保有コストを低く保つ
• 開発手法に着目
  • アジャイル
  • スクラム、XP
• 問題設定力 x 開発力 x チーム力 = ソフトウェアが生み出す成果
• レガシーコードを最初から作らないようにするためには
  • やり方より先に目的、理由、誰のためかを伝える
  • 小さなバッチで作る
  • 継続的に統合する
  • 協力し合う
  • CLEANコードを作る
  • まずテストを書く
  • テストで振る舞いを例示する
  • 設計は最後に行う
  • レガシーコードをリファクタリングする
• やり方より先に目的、理由、誰のためかを伝える
  • プロダクトオーナー(What)と開発チーム(How)の役割の違い
  • WhatとHowを分離する
  • やり方を明示されると選択や交渉の余地が減る
  • 作る上で重要なのは、まずコンテキストを共有すること
  • 「ユーザーストーリー」
    • 機能について会話できるくらいのかろうじて十分なドキュメント（仕様書ではない）
    • ストーリーが限定的であることで、テスト可能になる（受け入れ基準と自動化）
    • シンプルに始めて追加は後で行う 斬新的にすすめることで、良い設計が浮かび上がってくる
• 小さなバッチで作る
  • タイムボックス（期間）とスコープボックス（機能・タスク）
  • QCDS（品質、リソース、時間、スコープ）
    • スコープと時間を柔軟に考える
    • リソースという単語は人間には適用できない
    • 人を追加すると、やり取りが増えて速度が落ちていく
    • 品質を犠牲にすると、あとから辛くなる
  • ケイデンス、リソース効率、プロセス効率
    • ケイデンスが長くなると、リソース効率化を目指しやすい
    • ケイデンスを短くすると、プロセス効率化上がる
      • 同時に着手するものを減らす必要 　- モブプログラミング＝究極の1個流し
  • ソフトウエアの評価
    • 顧客にとって価値あるものに基づいて評価すべき
    • 完成して初めて価値になる
    • 価値実現めでの時間が期待したとおりか？
  • フィードバックサイクル
    • 小さなバッチのほうがフィードバックの回数は増える
    • フィードバックへの対応をサポートする文化が必要
    • 価値やリスクに応じて取捨選択する
• CLEANコード
  • チームで理解して、良くない例を避ける必要がある
  • 従うべきガイドラインも必要
  • Cohesive
    • それぞれの部品は1つのことだけを扱う
    • 名前重要
      • クラス名にdataがついていたり、メソッド名にcheckがついているのは危険
  • Loosely Coupled
    • オブジェ事感の関係を明確な糸を持った状態に保つ
    • 何でもできる神APIを避ける
  • Encapsuketed
    • 実装の詳細は外から見えなくなっている
    • 呼び出し側の観点で機能を設計する
    • 必要に応じてあとから公開することはできる
  • Assertuve
    • 自分の管理は自分でする
  • Non redundant
    • DRY原則
    • コードが違うから冗長ではないということではない
  • テストしやすさと密接な関係がある

感想

• やはりServerlessへの流れが大きくなってきていると感じました。
• レガシーコード、思い当たるところが多々あったので書籍を購入したいと思います。
• amazonで納期2〜5週間って。。