こんにちはかれこれ１０年程Salesforce界隈に住んでいます。 さえき(yonyonsaeki) です。
本日は、 Herokuアドベントカレンダー7日目の記事ということで、
Herokuの見積〜設計〜開発・運用におけるTipsをいくつかご紹介します。
最近はコンサルやプリセールスなどビジネス寄りの人間で、皆さんほどDeepな話は書けません。
とはいえ初中級系ネタは一定の需要ありと信じ今年のSWTTでフレクトさんと登壇した際の内容を元に記載させて頂きます。
一緒に登壇頂いたsshuさんは、18日目に多分Addonsの話書いてくれるみたいです。期待。
当日は前後半に分けて、
前半にHerokuっていうのは、"こんなところが凄くて、ビジネス的にこんなシーンで必要とされることが多いんだよ"ということをお話しましたが、
後半に実践的なTipsをいくつかお話しましたのでそちらから抜粋します。
サマリ
各章共に、黒文字タイトルが基本ぽい話、赤文字がちょっとニッチなTips話です。
見積・サイジング系
基本
HerokuはAWSの構成検討やサイジングよりもシンプルですが
ちゃんと考えないと想定ユースケースに対してリソースが足りなくてリリースできないなんてことになりますのでちゃんと考えます。
Dyno,Addon,HerokuConnect,PrivateSpaces
考えるのはほぼこれだけです。これらを構成してアプリケーションサービスを構築します。
- Dyno
- Linuxコンテナ。Webサーバやバッチ処理サーバなどの用途になります。少しややこしいので後述。
-
Addon
- 必要なアプリケーションサービスをリンク先のストアから選びます。例えばメール送信サービスなら、メール通数やWebhook有無など必要なプランを選択して料金を積み上げ。
- HerokuConnect
- SalesforceCRM上のオブジェクトデータとHeroku上のマスタデータを連携させる時なんかに必要。同期対象テーブルの行数が何行になるかによってライセンスプランが変わります。(1日あたり同期するレコードの連携件数が何件あるか、ではないのでご注意)
- PrivateSpaces
- VPCなサービス。東京リージョンも払い出せるので、ポリシー的に国内が、とかセキュリティ的にとかなどの要件があれば利用を検討する。
Tips(見積編)Dyno選び
Dynoは大きく３タイプ
1.WebDyno 2.WorkerDyno 3.One-off Dyno に大きく分けられます。主には1と2です。その性能と並列度を考えます。
配置数=Dyno数ではない DynoUnitsを理解する
EC2のサーバーのように、スペックや用途でいろんなDynoがあります。
性能の高いWebDynoをStandard-2xDynoで2台並べたら、2unitsを２台なので4Dynoの消費になります。
また、PrivateSpacesに配置するDynoはprivate-s以上を選択する必要があります。性能は非常に高くなりますがunit数が多くなります。
dev環境,stg環境,prod環境ごとに構成を検討し合計数 ＋ バッファ10-30%程度(One-offのように常時起動でない分や１時的なスパイクへの対応)を必要数とするのが良いと思います。
設計編
基本
アプリの設計というよりはアーキテクチャ・アドオン構成の話になります。
例として決済を含むようなBtoCアプリをイメージしています。HerokuとSalesforceのCRM製品の棲み分けなんかもご参考ください。
オレンジ枠で書いた部分が、Addonと呼ばれるHeroku純正のサービスやSendGridのような有名なアプリケーションサービスを活用したい部分です。
かなりの部分をスクラッチせず組み合わせて全体のサービスを構築できます。
Tips(HerokuConnect 同期件数を抑えたい場合)
プラットフォーム純正のものがうまくフィットしなければつくりで頑張る、ということが
一定量あるのがプラットフォームを活用した開発の通例と思いますのでそんな一例です。
HerokuConnectはSalesforceのCRMデータと双方向同期できるマネージドなサービスです。
超簡単にデータの双方向連携が実現しますので有り難いです。
前述の通り、HerokuConnectは同期対象とするテーブルの総レコード件数のボリュームでライセンスが代わってきますので初期構築後のデータ増加ボリュームを考慮する必要があります。
会員に対してn件、さらにその明細テーブルでm件、、と時系列に増えるテーブルを同期するとあっと言う間に同期件数が増加するため、よほどレコードバリューが高くないと割に合わない、と言う場合もあるかもしれません。
そこで例えば、こんなバケツリレーみたいなアーキテクチャを組むこともあります。
これはこれで、型化しやすいのと、SF側とHeroku側で分業しやすかったりするのでアリかなと思います。
賛否両論あるはずですが、支援に入った現場でほぼ必ず起きる議論だったりするので一つの方法として。
開発・運用編
基本
HerokuCI+PipelineでCI/CD
いわゆるHerokuFlowについて、HerokuCI/Pipelineの話をSWTTでした訳ですが
1日目の usk さん、またその中に組み込まれるReviewAppsの新機能について、 4日目中の人 masamis さんが既に書いていただいていますので、そちらで・・・
Tips(ログ・メトリクス系アドオンの効率運用)
ニッチすぎてうんざりしますが・・・
Herokuの管理App自体は2日目 zunda さん記載のDataClip他
色々と便利な機能はあるので、よく触ってみましょう。という動機付けとして。
例えば、各環境自体にlog管理のアドオン入れたい場合、
各アプリにアタッチするのですが、devで追加機能の動作確認しながら、prodで別件の調査とかしてたりすると
アプリ切り替え->ログ画面遷移、を繰り返すことになったりして少し面倒です。
そんな時はこんな感じで、集約用のAppを立ててそこにリッチプランのログアドオンを割り当てし、
そのアドオンを他のアプリにもアタッチする、ということができます。
(ログ管理アドオンにアタッチするアプリを追加する画面)
(ログ管理アドオン上のスイッチャで簡単に監視対象アプリが切り替えられる)
まとめ
他のAdvent参加者の方と同様、Heroku大好きです。
本当は皆さんみたいにコアでギークになりたいけど、Herokuよく分からなくて嫌いになりそうな人は、
手始めに浅く広くな私まで一度相談いただくと良いと思います！
また、開発者目線で、初めてHeroku触るときに少なくとも絶対知っておくべき(必ず触れる)クセみたいなものは
@seijikoharaさんが、12日目 "初めてのHeroku開発"の前に〜Herokuのクセを理解する〜で書いてくれてますので、
是非チェックしてください。
良いお年を。