サーバーレスへの道(1) ~DevOpsと人~

記事タイトルとURLをコピーする

サーバーレスとDevOpsについて何か書こうかなーとネタ探しをしていたところ、A Cloud Guru の John McKim (@johncmckim) さんが書いた記事「Adopting Serverless — People and DevOps」が面白かったので、John さんに許可をとったうえで翻訳してみました。

https://twitter.com/johncmckim/status/791857724925612032

↓ここから翻訳↓


サーバーレスへの道 ~DevOpsと人~

サーバーレス導入にあたって考えるべきこと

サーバーレスアーキテクチャはクラウド業界にて大きな注目を集めています。2016年にAWS Summitやデベロッパーのイベントにでたことがある方ならば、サーバーレスが大きなテーマになっていることが分かると思います。サーバーレスを推進しているのはAWSだけでなく、Azure,Google,IBM、また WebTask も力をいれています。

世界中にはサーバーレスを使ってシステムを構築している多くのデベロッパーがいます。A Cloud Guru では2015年に完全にサーバーレスでできたトレーニングシステムを構築しました。これによりシステムの改修やスケールの拡張が簡単にできるようになりました。

しかしサーバーレスアーキテクチャは本当にいいものなのでしょうか?サーバーレスで構築する前に、何を考慮するべきなのでしょうか?

数週間かけて私たちはサーバーレス導入にあたって検討すべきことを話し合い、その中で A Cloud Guru 内の経験をもとに、必要と思われることをピックアップしました。

ソフトウェアは人によって作られます。まずサーバーレス導入にあたって最初に考えるべきことは、「人」です。

知識

サーバレスでシステムを作る時に、まず開発者は数あるクラウドサービスから何を使用するか選択する必要があります。使用すると決めたサービスがどれほど使えるのか、またどのように動くかといった知識は非常に重要です。

AWS上でメッセージサービスを構築しようとした時、SNS,SQS,Kinesis,そしてDynamoDB streamsが選べます。各サービスはAWS Lambdaと異なる形で連携ができ、また異なる形でエラー処理を行うことになります。何のサービスを使ってシステムを構築するか、こういった違いを理解することが非常に重要になります。

チームメンバーがクラウドサービスに慣れていない場合は、Meetup groups や、オンラインフォーラムを使って、他のエンジニアと交流することができます。AWSについてもっと勉強したいときは、A Cloud Guru のオンライントレーニングをご利用ください。

各クラウドサービスへのアクセス

サーバーレスでできたシステムは、大抵複数のクラウドサービスからできあがります。4人の開発メンバーが、5つの異なるクラウドサービスを利用することを想像してみてください。各開発メンバーに対して、一つずつアカウントを発行しますか?開発メンバーは、複数のデバイスでアカウントを使うことができますか?またアカウントを本番用、検証用と分けるのでしょうか?サーバーレスでは、管理しなくてはいけないサービスの数はどんどん増えます。

クラウドサービスへのアクセス管理は大切です。各組織はメンバーの入社、退職にあわせて、アクセス権限の管理を行わなくてはいけません。パスワードマネージャは、こういった問題の解決に役立ちます。大きな組織には、SSO(シングルサインオン)が役に立ちます。SSOが対応していないサービスには、自前でアカウントを作らないといけませんけどね。

DevOps

サーバーレスは「NoOps」であるという誤解がよくあります。サーバーの運用がなくなるからといって、運用そのものがなくなるわけではありません。テスト、デプロイ、ログ管理はまだまだ必要です。

開発プロセス

開発プロセスとコードの品質には、密接な関係があります。開発メンバーがツールと格闘している場合、いいコードは書けないでしょう。

サーバーレスでの開発に役立つフレームワークは複数あります。Serverless Heros がツールとフレームワークのリストを用意しています。ツールを選ぶ際には、以下の点に注意してください。

  • リソースをどう明確にするか?(※)
  • どのくらいクラウドにデプロイするのが簡単か?
  • オフラインで開発できるか?
  • サポートとコミュニティはどんな感じか?

    ※訳注:AWS Lambdaのファンクション等、使用しているサービスのリソースを意味していると思います

チーム開発が強いこと、コミュニティが活発であることから、A Cloud Guruでは Serverless Framework を選択しました。

デプロイ

マイクロサービスのデプロイに詳しい方は、サーバーレスのデプロイは珍しいものではないでしょう。マイクロサービスと同様に、サーバレスもシステム個別にデプロイが可能であるべきなのです。こういったシステムを作るには、このことを肝に命じて開発をしなくてはいけません。

サーバレスの機能は、インフラ部分に依存します。Infratructure as code はサーバレスには必須です。サーバレスへのデプロイには、リソースの準備と、コードのデプロイが含まれており、サーバレスフレームワークといったツールがこういった部分を手伝ってくれます。Serverless Framework はAWSへのコードのアップロードと、CloudFormationをつかったリソースの準備をしてくれます。

テスト

サーバーレスのシステムにもテストが必要です。ユニットテストと、結合テストをしましょう。特に目新しいことはありません。サーバレスシステムは複数のサービスを統合しています。違いと言えば、マイクロサービスがどれだけ外部のサービスに依存しているかということにあります。

外部のサービスに依存している部分のユニットテストを行うには、外部サービスから切り離して行いましょう。ユニットテストを書いている時に、多くのサービスのモックが必要であることに気づくかもしれません。

結合テストはサーバーレスでは特に重要です。各サービスが、依存しているサービスと調和しているかを確認することが目的です。サービスをテスト環境に展開し、サービス間の依存関係をテスト環境に落とし込むこと必要があります。外部サービスのテスト用アカウントを作らなくてはいけません(例:Auth0, Stripe...等)

サーバーレスのテストは難しいですが、適切に行うことが大切です。

ロギングとモニタリング

あなただったら、アクセスできないサーバ上で動いているアプリケーションのどうモニタリングしますか?それに加え、コードが独立したファンクションで動いている場合には、どうやってモニタリングをすればいいでしょうか?

FaaS(訳注:Function as a Service)では、ログの取得と保存がサービスプロパイダに求められ始めています。AWS  LambdaではログをCloudWatchとWebTaskに送るので、リアルタイムでのログストリーミングが可能です。

しかしこれらのサービスは、エンドからエンドへのログを関連付けることることまではやってくれません。もし仮にこのようなサービスがあったとしましょう。
1bxkwsz2cinyergz1fomh5gエラー対応には2つのLambdaファンクションのログの確認が必要です。手動で行うことは、難しい、あるいは不可能でしょう。

モニタリングはロギングが全てではありません。ログ以外の障害、実行時間、CPU、メモリ、といったメトリクスが必要です。AWSではCloudWatchがベースとなるメトリクスを提供してくれます。IOPipe のようなサービスは、サーバーレスファンクションのより詳細なモニタリングを提供することを目的としています。

What’s Next?

DevOpsと人だけが、サーバーレスに向かうための要素ではありません。私の次の記事では、アーキテクチャ、セキュリティ、そしてアウトソーシングに関連した問題をみていきます。

もっとサーバレスについての記事を読みたい方は、私の Medium か Twitter をフォローしてください。

私自身と A Cloud Guru のチームではサーバレスのトレーニングシステムをつくっています。AWSの資格や、もっと AWSLamdba を学びたい方は、サインアップして勉強を始めましょう。


↑ここまで翻訳↑

いかがでしょうか。サーバーレスのシステム構築に向けて、具体的なイメージが出て頂ければ幸いです。英語が得意な人は、 A Cloud Guru でAWSのお勉強をしましょう!

John さんの今後の記事についてもウォッチを続け、皆様にご紹介できればと思います!

ではでは

次の記事
サーバーレスへの道(2) ~アーキテクチャとセキュリティ~