MANABIYA1日目に行ってきた

3/23,24に開催されたMANABIYA(https://manabiya.tech/)の1日目に行き、
機械学習ハンズオンとインフラ系セッションに参加してきました。

普段はネイティブアプリのサーバーサイドエンジニアとして働いており、
業務で機械学習を活用したりインフラ領域に深く携わることはありませんが、
今後理解を深めていきたい分野のためせっかくの機会と思い参加しました。

Python + Keras + TensorFlowによるディープラーニング実践（入門）

aidemy.net

AidemyのCEO石川氏によるハンズオン形式のセミナー

内容としてはAidemyの機械学習概論(https://aidemy.net/courses/2010)とディープラーニング基礎(https://aidemy.net/courses/5090)に基づいたもので、機械学習に関する解説と深層学習による手書き文字認識、画像認識についてKerasを用いてJupyter Notebook上で実際に動かすといったものでした。

解説がわかりやすくハンズオンでも実際に動かすイメージを持つことができて非常に良かったので、今後Aidemyの各コースも一通り受けてみようと思います。

本気で機械学習やる人のためのハンズオン ～教師データ作成から学習・性能評価まで～

www.slideshare.net

来栖川電算の方々によるハンズオン形式のセミナー

はじめに機械学習の概要と向き不向き、機械学習プロジェクトの進め方について解説がありました。

以下解説メモ

  • 機械学習とは
    • 人間の学習能力や推論能力を機械に模倣させる手法(自動プログラミングの一種)

  • プログラミングとの対比

    • プログラミング：推論のプロセスを人間が考えて記述。実装仕様が明らか。
    • 機械学習：具体的な実装仕様がわからなくても適用可能。ただし膨大なデータが必要

  • 機械学習プロジェクトについて

    • タスク設計とデータ収集・アノテーションが重要
    • タスク設計
      • 機械学習に向いているタスクに落とし込み適用できるか
        • 経験によって精度が上がるものか、データは十分に用意できるか、etc...
    • モデルやデータパイプラインの工夫よりもデータを揃える方が先
      • 認識できるデータか、そのデータから推論できるか
    • サービス運営では溜まっていくデータを活用してより精度を高めていく

  • 機械学習プロジェクトの進め方

    • 仮説検証の繰り返し
    • AIエンジニアとデータ管理エンジニアが協力してルールを考案し、よりよいタスクへ再定義していく
    • 精度評価においてもタスクに応じて見るべき指標が異なってくるため、タスクを確定させていきながら見るべき指標を絞っていく

ハンズオン資料 github.com

ハンズオンはAWS SageMakerを使ってJupyter Notebook上で花札の画像認識の実装を体験するというものでした。

AnnotationFactoryという来栖川電算のプロダクトを用いて作成された教師用花札画像データをSSD (Single Shot Multibox Detector) モデルで学習させる転移学習です。

AWS SageMakerについては日本リージョンではまだ利用不可であり活用事例は少なく費用面も高めなので実務想定の話ではありませんでしたが、Jupyter Notebookの含まれた機械学習を容易に試せる環境として選択したとのことでした。

マイクロサービスアーキテクチャとサーバレスからDevOpsへ

アマゾン ウェブ サービス ジャパン株式会社 プロダクトマーケティングエバンジェリストの亀田氏による講演

AWSの歴史の紹介と設計思想やインフラ技術、開発手法など幅広い解説がされていました。

以下講演メモ

  • AWSの由来

    • cloudではなくweb service
    • web serviceとAPI
      • 2000年初期web技術が進化し基幹系や複雑な業務もweb化
      • 異なるシステムをAPI経由で接続するように

  • Amazon

    • 最初はモノリシックアーキテクチャ
    • SOA(Service Oriented Architecture)
      • システム間のコンポーネント接続はhttpsのAPIのみ
      • 互いがブラックボックスとなり、開発効率が向上した
      • マイクロサービスの概念
      • サービスの集中型のマネジメントを最小化(ゼロになるものではない)
    • Two-pizza teams
      • チーム内部は密結合になることもある
        • この規則を超える人数のチームは作らない(コミュニケーションコストが肥大化することを防ぐ)
      • DevOpsの概念
      • 厳密にインターフェースを保つ
        • 保つことができなければデグレが生じる
    • 数千のチーム × マイクロサービスアーキテクチャ × 継続的デリバリ × Infrastructure as a code = 年間5000万回のデプロイ
    • Infrastructure as a codeの内部分解
      • Dev側のインフラ管理コストを極小化
    • DevOps
      • 文化
        • Dev,Opsの中間プロセスの壁を取り払うものであり、一緒にすべきということではない
      • 実践
        • アジャイルが必須というわけではない、ただ相性がいい
      • ツール

  • AWSのサービスから見る変遷

    • 初期
      • Auto Scaling
      • セッション情報共有Pool
      • 最新アプリケーションデプロイ
        • AMI再生成パターン
          • 緊急時の対応などに対しては重い
        • Bootstrapパターン
          • OSの新規立ち上げの時間がかかる
        • Loadingデプロイ
          • 一台ずつ切り替えていく
    • コンテナ、サーバレス
      • ECSの基本構成パターン
        • OSが新規で立ち上がるなどの時間は減らせる
        • 常駐しているインスタンスの費用はかかる
      • AWS Lambda
        • セキュリティは関数単位でかける
        • イベント単位でコンテナが立ち上がる
        • 実行は最大300秒
        • 再利用されることもあるがその条件をAWSは公開していない
          • ステートレスが求められる、またDBへのコネクションプールがないので基本的にはNoSQL(DynamoDBなど)を利用する
        • 初期起動に時間がかかるコンパイラ言語(Java,Goなど)よりもPythonなどのスクリプト言語との相性がいい
    • EKS,Fargate
      • EKS
        • ハイブリットクラウド対応
        • kubernetesは世の中に展開されているライブラリが豊富、それをAWS上で使える
      • Fargate
        • Lambdaの拡張
        • オートスケーリングよりも早くスケールする

ソフトウェアの設計においてもインフラのリソース管理においても開発組織の形成においても、構成要素を必要最小限の粒度まで落とし込んでインターフェースを厳密に管理し疎結合にすることで効率とスケーラビリティが得られるということがよくわかった。

小さくすることはあくまで手段であり、解決したい課題が先にあってこそなので、その課題を正しく見出すことも大事だと思った。

その意味でもインフラ面について単に実装に必要なサービスを知るだけではなく、コスト面やリソースの最適な活用、あるいは継続的なデプロイのためのパイプラインをいかに整備するかということにも意識を向けて様々なプラクティスを知りたいと思った。

マイクロサービス on マルチクラウド

株式会社メルカリ SRE/プリンシパルエンジニア 長野氏による講演

メルカリのインフラの歴史やマイクロサービスとマルチクラウドの運用事例とマルチクラウドの課題についての紹介

以下講演メモ

  • メルカリのシステム概要

    • 大量のリクエスト
      • 出品における画像アップロード、DB書き込み、Search反映、AIによる価格レコメンド、TL反映
      • 購入処理
    • 高速に並行して大量のトランザクション処理を行っている

  • マルチクラウドの構成

    • JP : さくら
    • US : AWS
    • UK : GCP
    • これらに加え最近は各リージョンでGCPと組み合わせられ始めた

  • インフラの歴史

    • 2013
      • JPでさくらのサーバー1台からサービス開始
      • 開発者に身近だったのがさくらだった
      • 2ヶ月くらいでさくらのクラウド、専用サーバに移行
      • さくらの専用サーバ
        • Metal as a Service
        • コストパフォーマンスが良い
    • 2014
      • USでAWS(オレゴン)にてサービス開始
      • 背景として開発者にAWS経験者が増加
      • インフラ専任者が少なかったのでマネージドサービスもよく使った
      • MaaSも検討したがサービス成長が読めず、柔軟なクラウドに寄せた
    • 2015
      • SREチーム発足
    • 2016
      • UKでGCPにてサービス開始

  • IaaSを中心としたマルチクラウド

  • オペレーションの共通化・少人数運用の実現

  • シンプルな三層構成

    • EC2/GCEを主に利用

  • internal DNS

    • 全てのサーバにunboundを導入
    • ローカルキャッシュによるパフォーマンス向上
    • resolv.confより障害に強い

  • サービスの可溶性と柔軟性を確保

    • アプリケーションはIPアドレスではなくホスト名を利用
      • アプリケーションコードの変更とそのデプロイなしに構成変更が可能
    • internal LB代替としてconsulを使った冗長化と負荷分散

  • マイクロサービス

    • サービスのレジリエンス向上
      • 細かいスケーリングと障害の分離
    • チーム、組織のスケーラビリティを高める
      • 1000人以上のエンジニア組織を志向
      • サービスの開発速度の向上

  • USリアーキテクチャ

    • USマーケットへの最適化のためクライアントをフルリニューアル
    • APIゲートウェイをGoで実装
    • 緩やかな移行を実現

  • APIゲートウェイ in JP

    • マイクロサービスを進めるため

  • Kubernetes

    • AWS EKS, Fargateの検証
    • k8s on Metalの検証

  • Spinnakerhttps://www.spinnaker.io/の採用

    • デプロイパイプラインを定義、自動実行

  • マルチクラウドの課題

  • 今後について
    • 引き続きマイクロサービス化を進めて特定のサービスが落ちても全体に影響させない
    • 高可用性が求められるサービスはマルチクラウド化、土台となるサービスは一つのクラウドのサービスに絞る、など

調べてみると以前からメルカリのマイクロサービス化が進められている話やマルチクラウドの話について、技術的にはchoconやSpinnakerを実用している話について発信していたみたいだが、自分にとっては初めての話で面白かった。

一つのクラウドサービス(自分はAWS)でどのようにサービスを構築するか、新しいサービスの使い道をどうするかということについ捉われがちになっていて、それでもちゃんとしたサービスを構築して開発運用できていれば問題ないのかもしれないが、よりサービスの質を高めるためにはいくつかの主要なクラウドサービスのpro/conを知った上で活用する手法を考えるべきだと感じた。