エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

Developers Summit 2019 に参加しました #devsumi

f:id:uhm3:20190218132825j:plain

こんにちは。エンジニアリンググループ、SREチームメンバーの平岡(@uhtter)です。

先週の2/14~15に開催されました、Developers Summit 2019 に参加してきました！

2日間であった数多くのセッションの中から、いくつかのセッションの内容についてレポートしたいと思います。

event.shoeisha.jp

今回は平岡が特に気になった5つのセッションについて紹介します。 なお、全体の資料は以下のページにて随時掲載されていくとのことです。

codezine.jp

[14-A-2] GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS化

  • 登壇者：GitHub、ソリューションズエンジニアの池田 尚史さん(@ikeike443)
概要

今日の開発に関するワークフローは多様化・複雑化する一方であり、そのためのツールが乱立している。 開発者が本来注力したい作業はコードを書くことであるはずで、ツールの使い方を調べたり設定ファイルとのにらめっこに時間を使うのは望ましくない。 そこでGitHubは、開発に関するワークフローをモジュール化するプラットフォームとして GitHub Actions を提供する。(2019年2月現在beta機能)

  • GitHub Actions の特徴
    • コードのPush、PR発行、Issue発行など、26種類のイベントをトリガーにWorkflowを開始できる
      • エンドポイントへのJSONのPOSTでトリガーできる、RepositoryDispatchイベントもある
    • Workflowは連続したAction(実体はコンテナ)によって構成される
      • 一般的な作業（クラウドへのdeploy等）には、公開されている Action を指定して利用できる
      • 作法に則ったDockerfileを定義すれば、自分自身でもActionを実装できる
      • Filter Action でワークフローの条件分岐も可能
    • Workflowを定義するためのビジュアルエディタを提供する
      • 実体はHCL1のテキストであるため、Workflow自体もコードと同様にPR・レビューが可能
所感

コードを中心として開発者コミュニティを形成しているGitHubが 「コードのPushから始まるワークフロー」をプラットフォームに取り込んでいくことには違和感が全くありませんし、GitHub Actions 自体も開発者として素直に便利そうだと感じました。

途中までは「CIツールの置き換えになっていくのかな？」と思っていましたが、 CIツール関連のActionも既に用意されているようで、CIツールも包括した更に抽象度の高いワークフローに対応していくようです。 RepositoryDispatchによって外部からイベントをトリガーできる機構があったりと、様々な活用・応用ができそうだと感じました。GAが待ち遠しいです！

[14-C-3] サポートを、上手く使って迅速解決！‐現場が泣いて喜ぶ問い合わせ方法-

  • 登壇者：アマゾン ウェブ サービス ジャパン、シニアテクニカルアカウントマネージャの伊藤 裕史さん
概要

AWSサポートを正しく効率的に利用するためには、AWS自体を活用するスキルとは別の「質問するためのスキル」が必要になる。 この質問するためのスキルをAWS利用者にも習得してもらうため、ガイドライン2を作成・公開した。

  • ガイドライン全体は、4つのポイントに要約できる
    • 正しい基本情報の入力 / 課題の明確化 / 状況の正確な共有 / 経緯の共有
    • 誤りや不足があると、質問と回答の繰り返しが多くなる等、回答までの時間が長期化する原因になる
  • ありがちなミス・誤解
    • 問合せ言語の設定が誤っていると、質問言語のネイティブでないエンジニアに届いてしまう。
    • 「緊急度：低」なのに「本日中回答希望」と書かれても、システムとして当日中にエンジニアの目に入らない可能性がある
    • リソースの所有者以外からの問い合わせにはセキュリティ上答えられないし、サポートエンジニア自身もリソースの内容にはアクセスできない
  • サポートエンジニアの回答品質に評価を付けてほしい
    • AWSサービスに対する評価とは別に、回答内容からエンジニア個人を評価してほしい
    • 日本人はあまり★5を付けない傾向があるが、回答に満足できたのなら遠慮しなくても良い
所感

少し前に公開されて一部で話題になったAWSの技術サポートガイドラインについて、中の人からの解説をいただきました。

ありがちなミス・誤解として挙げられていた事例には、自分自身も知らずに踏みそうなものもあったので興味深かったです。 特に、サポートシステム上の制約やセキュリティ上の制限というのは利用者側にとって盲点になり得ると感じました。

自分も社内で技術サポートを担当することがあるのですが、4つのポイントとして挙げられていたものは間違いなく同意できるものでした。共感できただけでなく、参考にすることができそうなエッセンスも散りばめられていたと感じています。

[14-C-7] コンピュータビジョンを支える深層学習技術の新潮流

  • 登壇者：アマゾン ウェブ サービス ジャパン、機械学習ソリューションアーキテクトの鮫島 正樹さん
概要

コンピュータビジョンの領域の技術について、深層学習の台頭以降でのそれぞれの進展について説明した上で、それらの実用例について紹介する。

  • コンピュータビジョンの動向
    • コンピュータビジョンとは...
      • コンピュータに人間と同様の視覚を持たせようとする技術であり、認知能力なども含む
    • 深層学習以降の技術発展
      • 画像認識 / 物体検出 / 画像生成 / セグメンテーション
      • より発展した問題領域
        • GAN / コンテキスト認識 / 少量データ学習 / 敵対的画像生成・防御
    • コンピュータビジョンの開発技術
      • モデル提供 / ONNX / Define-by-Run / AutoML
    • コンピュータビジョンの運用技術
      • 推論環境の構築 / 推論結果の妥当性評価
    • コンピュータビジョンを支えるハードウェアの展開
      • 推論専用ユニット / エッジコンピューティングデバイス
所感

コンピュータビジョン分野から発展している技術の紹介として、非常に広範囲の内容について個々に深入りしすぎずにわかりやすく説明されているのが、率直に凄いと感じました。 「現在のコンピュータビジョン技術は、実用についても考えなければいけない段階に来ている」という理由から、開発技術、運用技術やそれに類するデバイスの話まで展開されていたので、とても聴き応えのあるセッションでした。

↑の概要がキーワードの羅列になってしまって申し訳ないですが、とにかくたくさんの内容を包括的に説明されていたので、（もし資料が公開されたら）ご覧になられることをお勧めします！

[15-C-1] OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -

  • 登壇者：NTT、OSSセンタの澤田 雅彦さん(@masahiko_sawada)
概要

NTTのOSSセンターでのPostgreSQLのOSS開発活動について、登壇者（澤田さん）の活動実績・感じたやりがい・課題を紹介する。

  • NTTがなぜPostgresのOSS活動をしているのか
    • NTTのお客様にPostgresユーザーが一定数居り、ユーザーからの意見が集まってくる
    • ユーザーの意見を基に開発することで、ユーザー↔開発者間のフィードバックサイクルを構築
  • 澤田さんの活動
    • 事実上、全ての業務時間でOSS活動をしている
      • バグ修正・機能追加で貢献 / 各種イベントでの登壇
    • 自身にとってのやりがい
      • 自分のコードに、海外の優れた技術者からの +1 が付くとうれしい
      • 登壇資料を準備している段階で自分の知識を棚卸しになるので、登壇には個人的なメリットが十分ある
    • 自身の課題
      • 英語に対する心理的な障壁はなくなったが、開発者会議でネイティブについていくのはまだ無理
      • 多くの人に仕事でOSS活動をしてほしいが、評価が難しい
        • コードでの貢献はともかく、レビューでの貢献は定量化し難い
        • 一方で、Postgresコミュニティは深刻なレビュワー不足
所感

「NTTでのOSS開発」ではなく「仕事でOSS開発すること」を軸に、登壇者の澤田さんが思いを語るセッションでした。 コードで貢献する例で「開発者の体験を改善する修正」というアプローチを紹介されていたりと、基本的な視座が「OSS開発コミュニティの中の人」にあるところが少し珍しくて面白かったです。

また一方で、「『仕事でOSS開発をすること』を広めていくためには、定量化できる評価の仕組みが必要」という制度設計に近い内容まで言及されていたのが興味深かったです。特に「レビューでの貢献は定量化が難しい」という指摘については、Postgresコミュニティの現状も踏まえてとても切実な問題だと感じました。

柔らかな雰囲気の一方で深く考えさせられる一面もある、密度の濃いセッションでした。

[15-B-7] 無意味なアラートからの脱却 〜 Datadogを使ってモダンなモニタリングを始めよう 〜

  • 登壇者：Datadog、Sales Engineerの池山 邦彦さん
概要

システムのモニタリングについて設計する際には、「なぜモニタリングするのか？」ということを自らに問い直すことが重要である。その問いに対して、モニタリングSaaSであるDatadogが何をどう実現しているかを紹介する。

  • なぜモニタリングするのか？
    • 「サービスのダウンをいかに早く見つけて、いかに早く直せるか」という至上命題を達成するため
  • Datadogの提供するモニタリング
    • Traces / Metrics / Logs
      • それぞれの用途は、問題発生時の原因特定 / トレンドやパターン分析 / インシデント調査
  • クラウド時代のモニタリング
    • Cattle, not pets
      • モニタリング自体をスケールさせるため、メトリクスをまとめて扱うアプローチが大事
  • 外形監視サービスを開始（2019å¹´2月現在Private Beta）
    • グローバルの複数拠点からHTTPエンドポイントにリクエストを投げる方式
所感

Datadogのサービス紹介だけにとどまらず、「モニタリングとして何を見るのか」「どう見るのか」といったところから、整理された道筋で丁寧に説明していくセッションでした。 最近話題の書籍の「入門 監視」についても口頭で少し触れていたりと、一般のモニタリングの考え方について啓蒙に近い部分もあって勉強になりました。

私個人（SREチーム所属）として、「モニタリングSaaSの提供者が、 "モニタリング" についてどう捉えているのか」というちょっと俯瞰気味の視点で聞いていましたが、非常に興味深かったです。 Datadogがで扱える異常判定のバリエーション、アラートレベル設計等、自分たちのシステムにおけるモニタリングで参考にしたい・できるかもしれない内容がいくつも含まれていたと感じています。

おわりに

今回、Developers Summitに初めて参加してみました。マニアックで濃いものもあれば、自社サービスの紹介と見せかけて一歩踏み込んだ話に展開するものもあって、油断ならない（失礼）セッションばかりで、想像以上に内容の濃いイベントでした。（終わった翌日は家で完全にダウンしていました）

セッション以外でも、展示されているブースが個性に富んでいたのが印象的でした。 言語の投票がすごいことになっていたり、全種類揃えたくなるバッチやペットボトルがあったり・・・などなど、見て回るだけでも楽しい空間だったと思います。

もしまだ行ったこと無いみなさんも、次回は参加してみることをお勧めします！

We are hiring!

エムスリーでは、エンジニアリンググループでの社内勉強会 TechTalk を定期開催しています。

Developers Summitには規模でこそ敵いませんが、内容の濃さ、幅広さではいい勝負しています（！？）

ご興味がある方は、↓のリンク先から参加登録してぜひ足をお運び下さい！

jobs.m3.com

  1. HashiCorp Configuration Language↩

  2. 技術的なお問い合わせに関するガイドライン - AWSサポート | AWS↩