以前「2018年の最先端DevOpsエンジニアになるためのロードマップ」という翻訳記事を投稿させて頂いたのですが、その記事は主に「オンプレ環境におけるDevOpsエンジニア」を想定した説明になっており、クラウドネイティブ時代の技術としては少々違和感があるかなということと、最近はDevOpsだけでなくMLOpsもかなり注目を集めているということで、今回は、私の考える「2019年のクラウド環境におけるDevOps/MLOpsエンジニアの標準的スキルセット」に関して述べてみたいと思います。
ちなみに現時点の私のスキルセットはこんな感じになっておりまして、下記で説明する技術の大体90%以上は一通り実務で経験済みですが、未使用の技術も含まれますので、記述内容に誤りがありましたらコメント欄等でご指摘頂けますと幸いです)
(2019/03/24追記)
下記のような関連動画もアップいたしましたので、宜しければこちらも是非ご参照頂ければと思います。
DevOpsエンジニアになる方法と将来性について
前提
「DevOps」の範囲は非常に広く、また人によって解釈がかなり異なりますが、この記事ではDevOpsの定義として「サービスを安定稼働させたまま、ユーザからのフィードバックを取り入れた新機能や改善を、迅速にサービスに反映するためのあらゆる取り組みや文化のこと」という前提で話を進めさせて頂きます。(MLOpsはDevOpsの機械学習バージョンという理解で問題ないと思います)
また、上記の通り「DevOps」は非常に範囲の広い概念であり、非テクノロジー的な要素も含まれますので「DevOpsエンジニア」という呼称は本来おかしい(職種の範囲が曖昧すぎる＆広すぎる)のですが、ここでは「DevOpsの目的を実現する上で必要なテクノロジー面のスキルセットを保持しているエンジニア」という風に考えて頂ければと思います。
また、開発工数および運用工数の削減がリードタイムの短縮には欠かせませんが、そのためには「可能な限りクラウドやSaaSのマネージドサービスだけで機能を実現する(巨人の肩に乗る)」ことがクラウドネイティブ時代のDevOpsエンジニアの必須条件というのが私の認識であり、そのためこちらの記事は「マネージドサービスを使いこなすこと」にかなり主眼を置いた内容となりますので、その点はあらかじめご認識頂ければと思います。
DevOps
まずはDevOpsエンジニアに必要なスキルセットを見ていきましょう。
AWSとGCPの各種マネージドサービスの知見
数年前であればクラウドに関してはAWSの知識だけで十分でしたが、ここ数年のGCPの進化により、サービスの新規開発の際に「IaaSとしてAWSとGCPのどちらを使うか」を検討するフェーズがほぼ必ずと言っていいほど入ってくるようになりました。
お客様の方では「GCPはより先進的(Kubernetesや機械学習系サービスに関してAWSよりも先行している)」というイメージがあるようで、(それ以外にもAWSに対する「技術者の飽き」もあると思いますが)「GCPを使ってみたい」という要望が増えており、2019年時点ではもう「AWSしか扱えないDevOpsエンジニアは時代遅れ」という状況になっていると考えて差し支えないでしょう。
両クラウドサービスの全てのマネージドサービスに関して詳しくなることは不可能ですが、一般的によく使用される下記のサービスの存在と用途とその対比に関してはある程度把握しておく必要があると思われます。
| 種類 | AWS | GCP |
|---|---|---|
| VM | EC2 | GCE |
| ストレージ | S3 | GCS |
| PaaS | Beanstalk | GAE(SE/FE) |
| FaaS | Lambda | Cloud Functions Cloud Run |
| コンテナ基盤 | ECS EKS |
GKE |
| RDB | RDS | Cloud SQL |
| NoSQL | DynamoDB | Cloud Bigtable Cloud Spanner |
| KVS | ElastiCache | Cloud Memorystore |
| メッセージキュー | SQS | Cloud Tasks |
| Pub/Sub | SNS | Cloud Pub/Sub |
| バッチ/ジョブフロー制御 | AWS Batch Step Functions |
Cloud Composer |
| ビッグデータ分散処理 | EMR | Cloud Dataflow Cloud Dataproc |
| 認証 | Cognito | Firebase Authentication |
| ロギング/モニタリング | CloudWatch | Stackdriver |
ちなみに、IT業界全体のシェアとしてはMicrosoftのAzureの方がGCPを上回っていますが、Web業界においてIaaSにAzureを採用している企業さんは2019年時点ではまだまだ少ないので、現状ではとりあえずAzureへのキャッチアップは後回しにしておいて問題ないと思われます。
クラウドアーキテクチャ設計
前述したAWSやGCPの各種マネージドサービスを適切に組み合わせてアーキテクチャ設計を行い、それを構成図に落とし込める能力は必須となります。
いわゆる「アーキテクト」という職種の担当領域でもありますが、「サービスを安定稼働させたまま、バリューをユーザに迅速に届ける」ためには、自動化のしづらい構成が採用されてしまったり、無駄な機能が開発されてしまったり、アンマネージドなツールやサービスが使用されて管理工数が肥大化したりしないように、アーキテクチャ設計の段階からDevOpsエンジニアが関与する必要があります。(小規模なサービスの場合はDevOpsエンジニアがアーキテクトを兼務する場合も多いと思います)
AWSやGCPの各種マネージドサービスに関しては、下記のような書籍でざっと学習して、どんどん実際に手を動かしてサービスを触ってみると良いでしょう。
Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版
【ダウンロード版】AWSをはじめよう ～AWSによる環境構築を1から10まで～
GCPの教科書
プログラマのためのGoogle Cloud Platform入門
VPCのネットワーク設計やIPアドレス範囲の設計に関する知識も重要です。拡張性を考慮した上で、自分なりのパターンを確立しておいた方が良いでしょう。下記の記事が参考になると思います。
AWSのネットワーク設計をサボらないでちゃんとやる
Amazon VPC IPアドレス設計レシピ
【AWSしかやったことない人向け】AWSとGCPのネットワークの違いを理解してみよう
Gitブランチモデルの適切な設計とタスク粒度の管理
ソースコードのバージョン管理を行うことは当然ですし、その場合大抵はGitを使うことになると思いますが、適切なブランチモデル(git-flow|github-flow|gitlab-flow|あるいはそれらのアレンジ版)を採用し、さらにタスクの粒度を小さく保っておかないと、コンフリクトやデグレードの可能性が高まり、「リードタイムを短縮する」というDevOpsの目的が達成できなくなってしまいます。
「これが絶対の正解」というブランチモデルやタスク管理の手法は存在しませんが、何らかの新機能を追加したりする際のコードサイズがどうしても肥大化してしまうようであれば、「フィーチャートグル」等を使用して、作業ブランチの生存期間を出来るだけ短くするように工夫する必要があるでしょう。
Git利用時のフローはどれを使うか
Pete HodgsonさんのFeature-togglesが面白かったので翻訳してみた
ちなみにGitブランチモデルに関しては、私の場合はgitlab-flowを基本にして、多少のアレンジを加えた方式で対応することが多いです。
インフラのコード化
インフラをクラウドのWebコンソールから手動で作成したり、あるいはサーバにSSHでログインして直接ライブラリ等をインストールする方式は、「別環境を作る際にまた手動で同じ作業を行う必要がある」「現在のインフラやサーバの構成を把握することが難しい」「手順書管理になってしまう」「属人性が発生する(いわゆる「デプロイ職人」が必要になってしまう)」等の様々なデメリットがありますので、リードタイムを短縮するにはインフラの構成は基本的に全てコード化して管理する必要があります。
インフラのコード化ツールとしては
といった辺りが一般的ですが、最近は特にTerraformの人気が高いので、Terraformに関しては必須知識になっていると考えて良いでしょう。
【ダウンロード版】Pragmatic Terraform on AWS
ただし、tfstateファイルをクラウド上で管理するために、AWSの場合にはS3バケットを、GCPの場合にはGCSバケットを事前に作成する必要があり、このtfstateファイル管理用のバケットの作成や削除も自動化したい場合には必然的にCloudFormationかDeployment Managerを使うことになりますので、この両者に関しても一応押さえておいた方が良いと思われます。
また、最近は
- Pulumi
- AWS CDK
といったツールも注目されており、まだメインストリームというほどには広まっていないという印象ではありますが、Terraformからトレンドが移行する可能性もゼロではないので、注視しておいた方が良いかもしれません。
Terraform と Pulumiを比較する
AWS CDK が GA! さっそく TypeScript でサーバーレスアプリケーションを構築するぜ【 Cloud Development Kit 】
コンテナ基盤とマイクロサービス
Dockerを活用することにより「環境の差異によって生じる様々な問題を防止できる」「デプロイやロールバックやオートスケールが容易になる」等の明確なメリットがありますので、コンテナ基盤に関する知識もDevOpsエンジニアにとっては非常に重要です。
コンテナ基盤としては、AWSだとまだまだECSやBeanstalkがよく使われているようですが、現状のトレンドから考えてKubernetesへのキャッチアップはDevOpsエンジニアにとっては必須と考えて良いでしょう。
AWSだとEKS、GCPだとGKEを使うということになりますが、最低限どちらのプラットフォームにおいてもマネージドサービスによるKubernetesクラスタの構築およびPod/Service/Ingress等のデプロイを行えるようになっておく必要があると思われます。
サービスメッシュに関しては、使うメリットがある企業さんは限定的だとは思いますが、AWSの「App Mesh」およびGCPの「Istio」に関してはある程度押さえておいた方が良いでしょう。(App Meshはまだほとんど使い物にならないという印象ですが、GCPではIstioを使うことが恐らく今後一般的になっていくと思われます)
Service meshとは何か
Kubernetes上でgRPCサービスを動かす
また、Kubernetesを使用したマイクロサービスの開発においては、言語は「Go」が採用されることが多く、そしてKubernetesクラスタ内でのマイクロサービス間の通信においては「gRPC」が使われることが多いため、GoとgRPCを使用した開発に関しても慣れておいた方が良いと思われます。
認証基盤
クラウドのマネージドな認証基盤を活用することで、アプリケーション側で認証コードを実装したり自分達で認証基盤を構築したりする必要がなくなりますので、アプリケーションの安全性や保守性が向上し、開発工数も管理工数も大幅に削減することが可能になります。
AWSだとCognito、GCPだとFirebase Authenticationが認証基盤を提供していますので、これらのサービスの概要に関してはある程度把握しておいた方が良いでしょう。(Cognitoは相当学習コストが高いですが、API GatewayだけでなくALBと連携できるようになってから一気に利便性が向上したという印象です)
最近はAuth0というサードパーティのIDaaSも注目されているようです。
サーバーレス/FaaS
何らかのイベントをトリガーとして処理を実行したい場合、自前で常時起動のサーバーを用意してAPIをホストするのは手間とコストが必要になりますが、FaaS(Function as a Service)を使えばサーバーレスで処理を実行できるので工数もコストも大幅に削減できます。
AWSならLambda、GCPならCloud FunctionsもしくはCloud Run(on GKE)がFaaSに該当します。
各サービスの設定方法やデプロイ方法、「最大実行可能時間」や「同時起動可能数」「複数回リトライされる可能性があるため冪等性を持たせる必要がある」という点、および「何らかのイベントをトリガとして起動できるFaaSと、単にHTTPのエンドポイントとしてのみ使用可能なFaaSがある」「VPC内のリソースにアクセス可能なFaaSとそうでないFaaSがある」という点に関してはある程度把握しておいた方が良いでしょう。
Amazon VPC 内のリソースにアクセスできるように Lambda 関数を構成する
VPC ネットワークの内部リソースへの接続 | Cloud Functions のドキュメント
Google Cloud Next 2019 in SF , サーバーレス関連発表まとめ
RDBのスキーマのマイグレーション
RDBのスキーマ変更が行われないWebサービスはまず存在しませんし、スキーマのマイグレーションを手動で行ってしまうと「属人性」や「オペレーションミス」という問題が発生することになりますので、マイグレーションをコードで管理して自動化することもDevOpsエンジニアの重要なタスクとなります。
こちらに関しても「これが絶対に正解」という手法は存在しませんが、私がAWSでRDB(RDS)のマイグレーションを行う場合は、大抵は「VPC Lambda」を使用しています。(Lambdaはコンピュート用のサービスなのでマイグレーション用ツールを実行可能であること、VPC LambdaはPrivateのRDSインスタンスにアクセス可能であること、Systems Manager Run CommandのようにEC2を常時起動しておいたりする必要がないので低コストなこと等、要件を満たしているため。ただし冪等性に注意する必要がある)
マイグレーションツールに関しては、個人的にはRidgepoleのように「スキーマファイルの差分を検出してDDLを自動生成してくれる」というツールが好みなのですが、実行されるDDLがコードレビュー時に分からないことや、スキーマ定義がツール独自のDSLに依存してしまうことが許容されない場合も多かったり、あるいはDDLだけでなくDMLを実行したい場合もあったりするので、一般的にはflyway系の、生のDDLやDMLをそのまま記述できるタイプのツールを使用する方が無難と思われます。
winebarrel/ridgepole
Flyway by Boxfuse
権限管理/アカウント管理
AWSもGCPも「IAM」という権限管理の仕組みがあります。システムを安定稼働させる上ではセキュリティは最重要要件の一つなので、権限管理に関しては十分に勉強しておく必要があるでしょう。
AWS IAM（ユーザーアクセスと暗号化キーの管理）
Cloud IAM - Identity & Access Management
AWSのIAMに関しては「Assume Role」の概念が最初は非常に理解しづらいと思います(私もしばらくAWSの案件から離れるとすぐ忘れてしまいます)。下記の記事等で学習しておきましょう。
IAMロール徹底理解 〜 AssumeRoleの正体
Assume Roleの用途・メリット
また、GCPに関しては以前から「開発環境」「ステージング環境」「本番環境」など、サービスや環境ごとにプロジェクトを分けるという手法が一般的でしたが、AWSも「AWS Organizations」の登場によってアカウントを非常にカジュアルに作成/削除出来るようになったため、今後はサービスや環境ごとにアカウントを分けるという手法が一般化していくと思われますので、こちらに関しても理解しておく必要があるでしょう。
(例えば業務委託の方は開発用のAWSアカウントのみアクセス可能にして、本番用のAWSアカウントは一部の社員の方だけしかアクセス出来ないようにすれば、サービスの安全性は大幅に向上しますので、今後は一つのAWSアカウントで全ての環境をホストするようなリスクの高い構成は廃れていくと思われます)
AWS Organizationsによるマルチアカウント戦略とその実装
AWS Organizations を実際に初めてみる第一歩
ビッグデータ分散処理
ビッグデータの分散処理に関しても、クラウドのマネージドサービスを活用することで、低コストで効率よく処理を実行することが可能です。
AWSならEMR、GCPならCloud DataprocかCloud Dataflowがビッグデータの分散処理基盤となります。
あくまで私の主観になりますが、「クラスタの管理をしないでよい」という点で、GCPを使う場合はCloud DataprocよりもCloud Dataflowの方が圧倒的に楽だと思います。Cloud Dataprocはクラスタの構築管理を自分達で行う必要がありますが、Cloud Dataflowは実行時に自動的にクラスタの構築とスケールと削除を行ってくれるので便利です。(DataflowはApache Beamのマネージドサービスです)
AWSに関してはEMR以外の選択肢がありません(AWS Batchも一応並列分散処理は可能ではありますがMapReduce系の処理には対応していません)。またEMRを使う場合は大抵の場合Sparkを使うことになると思いますので、Sparkの知識が必要になります。(過去の経験による個人的見解ですが、Apache Beamと比較すると、Sparkの学習コストはかなり高めです)
バッチ処理とジョブフロー制御
バッチ処理もバッチジョブのフロー制御も、現在はクラウドのマネージドサービス(の組み合わせ)で実現できるようになっています。
AWSであればStep FunctionsとAWS Batchの組み合わせ、GCPの場合はCloud Composerを使うことが一般的だと思います。
Step FunctionsとAWS Batchはそれほど難しくはありませんが、Cloud Composer(Airflow)は学習コストがかなり高い(特にWeb UIの使い方が非常に分かりにくい)ツールのため、使いこなせるようになるまでにはある程度学習期間が必要になると思われます。
また、Cloud Composerは、現時点では起動する際に最低でも3台のGCEインスタンスが必要になります(ComposerはKubernetesクラスタ上に構築されています)ので、ジョブフローの数がそれほど多くないサービスの場合はコスト面でかなり割高感があると思われます。
単体のジョブを実行したいだけであれば、GCPなら「Cloud Scheduler + Cloud Pub/Sub + Cloud Functions」という組み合わせでも実現可能です。(ただしCloud Functionsの最大実行可能時間には540秒という制限があります)
Pub/Sub を使用して Cloud ファンクションをトリガーする
また、私はやったことはありませんが、GKE上でJobを実行するという方法もあります。「とにかく何もかもKubernetesに寄せたい」という方針のチームであればこの方式もありかもしれません。
Running a job | Kubernetes Engine Documentation
CI/CDパイプラインの構築
CI/CDパイプラインの構築は、DevOpsエンジニアの最重要タスクの一つとなります。
CI/CDツールは色々ありますが、現時点では、一般的なWebサービスの開発においては「CircleCI一択」と考えて良いのではないでしょうか。
例えばAWSにはCodeBuildやCodePipeline、GCPにはCloud BuildというCI/CD用のサービスが存在しますが、「クラウドサービスのアクセスキー等の秘匿情報をCIサービスで管理してよい」という条件がOKならば、ほぼ全ての機能はCircleCIだけで実現可能なのと、CircleCIのノウハウはAWSでもGCPでもどちらでも共通で使えるので、わざわざ一つのクラウドベンダー限定でしか使用できないサービスに学習コストを浪費する必要はないのでは、というのが私の個人的見解です。
ただしCircleCIも安泰というわけではなく、GitHub Actionsが先日のバージョンアップでCI/CDをサポートしたことにより、将来的にはCircleCIからGitHub Actionsへの移行が進んでいく可能性がかなり高くなってきているという印象です。
現状のGitHub Actionsは「キャッシュ機能がない」「ブランチのフィルタリングが一括で行えない」等、CircleCIと比較した際に明らかに不便な部分が存在するようですが、ここら辺の問題が解決されれば、CircleCIを置換していくのは時間の問題かもしれません。(ちなみにGitHub ActionsのバックエンドではAzure Pipelinesのfork版が動作しているようです)
circleciのbuild/test/deployをgithub actions(beta)に移行した
新 GitHub Actions 入門
ロギング/モニタリング
サービスを安定稼働させる上でロギング/モニタリングは必須です。AWSならCloudWatch、GCPならStackdriverの使用方法にある程度詳しくなっておく必要があるでしょう。
サードパーティのモニタリングサービスとしては「Datadog」が比較的よく使われています。(はてなさんのMackerelも名前はよく目にしますが、私が今までに参画したプロジェクトでは使われていませんでした)
Datadogに関しては、ダッシュボードのUIコンポーネントが豊富だったり、Slackへの通知にグラフ画像を含めることが出来たり、外形監視を行えたり等、機能そのものが充実しているという点以外に、(完全ではないものの)唯一「Monitoring as Code」に対応しているツールであるというメリットもあります。(CloudWatchやStackdriverでもダッシュボードは作成可能ですが、環境ごとに全て手動で作っていく必要があります。監視する対象が多いとかなりしんどい作業になります)
TerraformとDataDogで始めるMonitoring as Code入門
クラウド時代の監視ツールDatadogをあらためて紹介します
DatadogのSynthetics(外形監視)つかってみた
分析基盤
ユーザのフィードバックをサービスに反映していく上で、分析基盤の構築もDevOpsエンジニアの重要なタスクとなっています。
AWSならRedshift、GCPならBigQueryが基本的な分析基盤となりますが、私が今まで参画した現場ではRedshiftを使っているチームはほとんど見かけませんでしたし、構築の容易さや、使い方を間違えなければ比較的低コストで運用できるというメリットから考えると、分析基盤に関してはとりあえずBigQueryだけ学習しておけば十分だと思います。
サードパーティのTreasure Dataというサービスを使っている会社さんもありますが、料金がかなり高めということもあって、こちらもBigQueryと比較すると使っている会社さんは少ないので、私も一応使用経験はありますが、あえて勉強しておく必要はないのではという印象です。
BashスクリプトとCLIツール
Bashスクリプトは、主にCI/CDにまつわる各種作業を自動化する上で必須のスキルとなります。
シェルスクリプトに関する書籍等で基本をしっかり学習しておきましょう。下記のエムスリーさんの研修資料もとても参考になると思います。
新しいシェルプログラミングの教科書
bashスクリプティング研修の資料を公開します
さらに、AWSの場合はAWS CLI、GCPの場合はgcloud、この2つのツールも自動化作業において必須なので、使用方法に関しては十分に詳しくなっておく必要があります。
AWS コマンドラインインターフェイス（CLI: AWSサービスを管理する統合ツール）
gcloud コマンドライン ツールの概要
基盤コードの開発
こちらも本来はアーキテクトの仕事になりますが、開発人数が少ない場合や、経験の浅いエンジニアの方が多い場合は、DevOpsエンジニアがアプリケーションの基盤コード部分も作成することになります。
私が基盤コードを実装する場合は、
- Webフレームワークの選定
- パッケージマネージャの導入
- サンプルAPIの実装
- 単体テスト
- 統合テスト
- Linterの設定
- Formatterの設定
- .gitignore等の設定
ここら辺までをざっと実装してから、アプリケーションエンジニアや機械学習エンジニアの方にお引渡しするというケースが多いです。
ちなみにAWSの各種サービスに依存する部分のテストに関しては、AWSのサービスをエミュレートしてくれるlocalstackというDockerイメージが便利です。
MLOps
次に、MLOpsエンジニアに必要なスキルセットを見ていきましょう。DevOpsエンジニアのスキルセットに加えて、下記のような知見が必要になります。
機械学習の基礎知識
機械学習の深い知見は必要ありませんが、実際にMLOpsエンジニアとして機械学習エンジニアの方たちと働いてきた経験上、とりあえず下記レベルの知識はあった方が良いかなと考えております。
- 微分と線形代数と確率統計の基礎知識
- Courseraの機械学習コース修了レベルの知識
- Jupyter Notebook(またはJupyterLab)の基礎知識
- KaggleのTitanicを一回やっておく
数学に関しては、大学レベルの知識は不要だと思います。高校3年生程度のレベルで十分だと思いますし、一回復習して大部分を忘れてしまってもMLOpsエンジニアとしてそれほど支障はないと思います。(ちなみに私の場合は下記の記事のように一ヶ月ほど仕事を休んで小学校の算数から高校3年生の数学までを全て勉強し直しました)
文系エンジニアが機械学習に入門するために小学校の算数から高校数学までを一気に復習してみました。
Courseraの機械学習コースは非常に評価の高いコースですが、実際に取り組んだ経験として「MLOpsエンジニアであればこのコースのカリキュラムをやっておけば機械学習の基礎知識としては十分」と考えております。(こちらは仕事をやりながら約1ヶ月程度で修了しました)
文系エンジニアがCourseraの機械学習コースを1ヶ月で修了したので振り返ってみました。
Jupyter Notebookに関しては、私の場合はフリーライブラリで学ぶ機械学習入門という書籍に取り組む中で勉強しました。ただし今後はJupyterLabが主流になるようですので、そちらの使い方に慣れておいた方が良いかもしれません。(GCPのAI PlatformではJupyterLab用のマネージドサービスであるAI Platform Notebooksが提供されています。
また、Kaggleの初心者向け課題であるTitanicに取り組むと、機械学習エンジニアの方たちの作業の流れが一応おおまかには把握できますので、こちらもやっておいた方が良いと思います。
【Kaggle初心者入門編】タイタニック号で生き残るのは誰？
機械学習基盤
AWSであればSageMaker、GCPであればAI Platformが機械学習基盤となります。(GCPの機械学習基盤は以前は「ML Engine」という名称でしたが、色々なサービスの追加や機能変更に伴って名称が変更されたようです)
どちらも
- 分析(Jupyter NotebookやJupyterLab環境)
- 学習
- 学習済みモデルのデプロイとAPIとしてのホスト
といった、機械学習基盤としての基本的な機能は共通です。
MLOpsエンジニアの場合、分析業務に関しては基本的に携わりませんので、それぞれのサービスを使用した学習の実行、およびモデルのデプロイとAPIのホストをどのように行うのか、という辺りが把握出来ていれば十分だと思います。
MLワークフロー制御
データの収集、前処理、学習、モデルのデプロイといった一連の機械学習のワークフローを制御する作業は、MLOpsエンジニアの最重要タスクとなります。
MLワークフロー制御に関して「これがスタンダード」というツールは存在しませんが、AWSであればStep Functions、GCPであればCloud Composer(Airflow)を用いることで、マネージドサービスだけを用いたMLワークフロー制御は一応可能です。
AWS StepFunctions を使った機械学習ワークフローの管理
Practical Guide: How to automatize your ML process with Airflow and Cloud Composer
AWSの公式ドキュメントに、Airflowを使ったMLワークフロー制御に関する記事が存在しますが、Airflowをアンマネージドな方式で使用することを許容できるならば、この方法もありかもしれません。
Amazon SageMaker と Apache Airflow
GCPの場合、GKE上でkubeflow pipelinesを使用してMLワークフローを制御するという方式が推されているので今後このツールの使用が広まっていく可能性もありますが、まだかなり発展途上のツールのため、今のところは静観しておいた方が良さそうです。
AutoML
データに対する前処理、学習アルゴリズムやハイパーパラメータの選定、学習と評価といった一連の作業(もしくはその一部)を自動で処理してくれるサービスを総称して「AutoML」と言います。(GCPの「Cloud AutoML」は単なるサービス名です)
AWSの場合、Amazon PersonalizeがAutoML系サービスの代表格だと思います。GCPの場合はAutoML Visionが有名です。
機械学習エンジニアの方やデータサイエンティストの方たちに色々お話を伺う限りでは、今まで機械学習エンジニアの方にお願いしないと不可能だった作業が、今後AutoMLによってどんどん自動化(いわゆる「AIの民主化」)されていく可能性が非常に高くなっているという情勢のようですが、AutoMLがうまくハマるタイプの作業であれば工数を大幅に削減することが可能になるため、「機械学習サービスのリードタイムを短縮する」ことが主要な役割のMLOpsエンジニアにとって、AutoML系の技術へのキャッチアップは必須になっていくと思われます。
まとめ
こちらの記事で紹介した全ての技術を短期間で経験するのは難しいと思いますが、「自動化」「巨人の肩に乗る」「モダンな技術を採用する」という方針の企業さんのご案件を複数渡り歩いていけば、クラウドのマネージドサービスを適切に活用する知見は自然と身に付いていくと思います。(少なくとも「手作業」や「オレオレコード」や「僕の考えた最強の社内ツール」的なものが蔓延している企業さんで働くことは、DevOps/MLOpsエンジニアのキャリアにとってはほとんどメリットがないと思います)
また、最初の方でも述べましたが、現在は「AWSとGCPのどちらをインフラとして使用するか」を検討するフェーズが新規開発案件の場合はほぼ必ず入ってくるという状況ですので、例えばAWSに関してある程度詳しくなったら次はGCPを使える案件を選択する等、プラットフォームにこだわり過ぎずに両クラウドのマネージドサービスを幅広く経験していく方が、より先進的で面白い案件に携われる可能性が高くなるのではないかと思います。(ちなみに私の場合はAWS案件とGCP案件を掛け持ちするみたいなこともやっております)
私もまだまだ「クラウドネイティブ時代のDevOps/MLOpsエンジニア」として発展途上ですので、今後も引き続き様々なマネージドサービスにキャッチアップして、サービス全体の安定性やリードタイムの向上にさらに大きく貢献できるように頑張っていきたいと思います。
おまけ
Youtubeの方で、Web系エンジニアやWeb系エンジニアに興味のある方たち向けの雑食系エンジニアTVというチャンネルをやっています。もしご興味ございましたらチャンネル登録してみて頂けると大変嬉しいです。
また、2019年から「雑食系エンジニアサロン」というオンラインサロンも始めました。(ご登録者様は2019年8月時点で1,200名様を超えました)
Twitterの方でも「Web系エンジニアのキャリア戦略」を中心に色々と情報を発信しておりますので、もし宜しければフォローしてみてください。@poly_soft