BrainPad株式会社ブレインパッドのデータ活用に関する取り組みや製品・サービス開発の裏側、社員の日常などをご紹介します。Francisco」の現地レポートを全5回の連載でお届けします!今回はその第3回です。Next)」で私が参加したブレイクアウトセッションについて紹介します!この記事の目次は次のとおりです。Nextでは、キーノートの他に500を越えるブレイクアウトセッションが行われました。suiteなど)も、その内容(新サービスの紹介や既存サービスの詳細、実際の応用例など)も幅広く、非常に多岐に渡ります。Engine(GKE)を利用した製品の開発をしており、その開発業務で役立ちそうなセッションを主に聞いてきました。その中から特に参考になった3つのセッションについて、2回に分けて詳しく紹介していこうと思います。3への移行についてのセッションを紹介します。Runなどのサーバレスなサービスを利用して、アプリケーションを開発する際のデザインパターンについて説明していました。ここでは、サーバレスを以下の性質をもつプラットフォームとして定義しています。・プロバイダによって管理されているこのようなサーバレスなサービス上でのアプリケーション開発におけるデザインパターンとして、以下が紹介されていました。Tasks等を利用し呼び出しが完了した時点で処理を終了する、というパターンです。このパターンに沿っていないコード例は以下のようになります。value)このような実装を行った場合、以下のような問題点があります。Function(GCF)やGAEのタイムリミットを超えてしまう・外部処理の終了を待つだけの何もしていない時間も課金の対象になってしまうBusy-waitのパターンを利用すると、上記のコードは以下のようになります。id})こちらの処理は、slowExternalOpの呼び出しが完了した時点で処理を完了します。次に、外部処理の完了イベントを受け取って、下記の終了処理を実行します。msg.value)このように書き換えることで、タイムアウトを樹にする必要がなくなり、無駄な課金も発生しなくなります。Stateでは、"仮に同じマシンによって処理されたとしても、マシンが再起動(あるいは再プロビジョン)されているなどの理由で前回のリクエストと同じ状態であるとは限らない"という問題が説明されていました。いずれの問題に対しても、"マシンの状態に頼るのではなく、キャッシュやDatastoreなどの外部にデータを保持する"ということが大切になります。parts非サーバレスなシステムをサーバレスなシステムへマイグレートしていく際に、システム内にスケーラブルではない部分があると問題になることがあります。前述のBusy-waitの例で、slowExternalOp()が同時に10個までしか並列で処理できないようなシステムの呼び出しだった場合、同じタイミングで11個リクエストが来てしまうと、そのうちの1つはエラーになってしまうといった問題が発生します。Tasksなどで置き換えることで、これらのサービスがバッファとして働いてくれて、開始リクエストの受付と実行できるようになるまでのリトライを自動でしてくれるようになります。このようなシステムへの呼び出しの制御やフィルタリングを行いたい場合は、GAEやGCFで実装したレイヤを間に挟むことも有効であると説明していました。automation"Gmailでメールを受け取ったら、10行程度のコードで書けるような簡単な処理を実行し作業を自動化したい"といった場合でも、サーバレス以前の時代であればハードウェアを準備したりミドルウェアをセットアップしたりと、様々な作業が必要でした。Functionにデプロイするだけで、このような自動化が実現できるようになりました。prototypingサーバレスなサービスを利用すると、アプリケーションの開発を素早く行うことができます。複数のAPIをまとめあげて何らかの処理を行うような、アプリケーションの開発に適しています。以前は素早いプロトタイプ開発とスケーラブルなシステムの開発は同時に行うことが困難でしたが、サーバレスなサービスを利用するとこれらを同時に行うことが可能となります。まとめBusy-waitのパターンなど既に利用しているパターンもいくつかあり、"確かにそうだよね"と思いながら聞いていました。非スケーラブルなシステムの扱いについてちょうど悩んでいた所だったので、このセッションで紹介していた内容を参考に、より良い解決法を探していこうと思います。2は、2020年にメンテナンスが終了します(https://pythonclock.org/)。上のアプリケーションに焦点を当てて説明していました。3へ移行することを推奨していました。3の両方で動作するように修正していく"というテーマについて、セッションでは詳細に説明をしていたので、ブログでも紹介したいと思います。futureについて説明されていました。環境で動作しないという問題があります。2環境でも動作させることが可能になるというものです。futureの方が少し便利な機能が多いようなので、この記事ではfuturizeとfutureについて紹介します。2のコードを変換すると、下記のコードが得られます。3に適した形に変換されていることが分かると思います。3環境でもそのまま動作させることが可能ですが、実際のアプリケーションのコードではツールでの変換だけでは不十分な場合があります。3では浮動小数点数を返すように変更されています。3へ移行する場合、このような挙動の変化は思わぬバグの原因となりますが、ツールを利用して変換することで挙動を変えないようにコードを書き換えてくれます。iterators次の例は、iterators’(イテレータ)と標準ライブラリのインポートについてです。変更されているので、ツールが自動で変換してくれます。configparserと全て小文字で書かなければならなくなりました。こちらもツールが自動で修正してくれます。3に移行する際は、下記のようなステップで行うと良いと紹介されていました。QueueやcronなどのGAE固有のサービスに依存していることがあります。3への移行の障壁となります。2アプリケーションのマイグレーションを考える場合には、ライブラリと同様にどのサービスを利用しているかの確認が重要になります。Python2.7環境上でそれらの代替サービスを利用するように修正します。3に変更することでマイグレーションの作業が完了します。Python2.7環境のサービスとその代替サービスについて紹介していきます。Queueとほぼ同じように利用することができます。queueが利用できないため、注意が必要です。PubSubを利用すると、同様の機能を実現することが可能です。tasksもサポートされておらず、現状これらのサービスの代替となるような機能は提供されていないため、これらの機能を利用している場合は自分たちで同等の機能を実装するか、既存の実装を変更するなどかなり大掛かりな修正が必要になりそうです。Tasksでは対応していないためローカル環境での開発について考慮が必要になります。Memorystoreが代替サービスとして利用することが可能です。3をサポートしておらず、現状ではdatastoreのクライアントライブラリ(https://googleapis.github.io/google-cloud-python/latest/datastore/client.html)を利用するように修正する必要があります。3に対応するndbの開発は進んでおり(https://github.com/googleapis/python-ndb)、現在はまだアルファ版ですができるだけ早くリリースしたいとのことでした。modeがdatastoreの後継プロダクトとなっており、データの整合性やトランザクション関連の機能が強化されているので、firestoreへ移行できるのであればそちらへ移行するのが良いと説明していました。2.7環境のサポート自体はしばらく続くとのことでした。2から3への、特にGAE環境上のアプリケーションの移行について、かなり実践的なセッションでした。3への移行を考えていたこともあり、かなり勉強になりました。3への移行についてのセッションを紹介しました。次回は、GKE上でのJava/Kotlinアプリケーションの効率的な開発についてのセッションを紹介します。採用ページスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。