質問: ### 前提・実現したいこと こんにちは。 今回、初めて質問させて頂きます。一般論を尋ねる質問になり恐縮ですが、回答頂けますと幸いです。 現在、pythonを学習している一環で、webアプリを作ろうと考えています。 このwebアプリはチャートを表示する程度のものですが、バックグラウンドの部分でAPIから情報を取得しDBに反映させるプログラムを走らせようと考えています。 概念図: クライアント ⇆ WEB・APサーバ ⇆ DBサーバ ⇆ API(別途プログラムを走らせることを想定) flaskの公式チュートリアルを通して、上記概念図においてクライアントからDBサーバの部分までの実装についてはイメージがつくのですが、それとは別にAPIから情報を取ってくるプログラムを走らせたいのですが、この場合APIから都度情報を取ってくるプログラムはどのようにデプロイするのが一般的なのでしょうか。 私の中では2通りの方法をイメージしており、一つはさくらのVPSサーバのようなものを借りて、webアプリを走らせる仮想環境(venvのようなものを想定)とAPIから情報を取得する仮想環境の2つを構築して2つを走らせてしまう方法が1つ、もう1つはWEBアプリはさくらのVPSサーバ、APIから情報をとるためのプログラムはAWSで走らせ、DBサーバと接続させておくというものです。 上記は、私のイメージになってしまうので、一般的にはどのようなやり方で行われるのかご教示いただければと思います。また参考サイトなども教えていただけるとなおありがたいです。 当チャートについては、株や為替などのリアルタイム性があるものを想定しており、APIのアクセス制限にかからない範囲でリアルタイム性を持つようなプログラムを書く予定です。 冗長かつ一般論での質問で恐縮ですが、どうぞよろしくお願いします。
回答: どっちでもいいというのが答えのように思いますが、(DBと取得用サーバを)別サーバで走らせる長所短所を考えてみてはいかがですか? 短所から DBと情報取得が異なるサーバ上で走ると、自身で管理している限り通信が2つ分増えます。一度取得した情報を(取得サーバから)送信して、また(DBで)受信する必要があります。 データをやり取りする量が多いのであれば、その分コスト(金銭的に、タイムラグ的に)がかさむことになります。 予算が無限なら特に考え必要がありませんが。 また、通信経路を増やすことで障害可能箇所が増えます。 それに伴って、例えば、取得サーバが死んだ時にデータがアップデートされなくなりますが、そのことをフロント側に知らせる必要があるのか、などを考えねばなりません。 長所について サーバを分割したので、DBが載っているサーバへの負荷が低くなります。 また、DBの負荷に応じてDBへのデータ転送量を制御することができるようになります。 例えば、DBへのアクセスが増える時間帯は取得サーバとの同期回数を減らすなどができます。 取得用サーバのスケールアウトのデザインが簡単になります。 事前にサーバを分けないとダメになることが目に見えているのではない限り、個人的にはとりあえずシングル構成で作ってしまうと思います。 その際にちゃんとログを取るようにして、負荷に応じて設計を再検討するかと。 仮想化技術でポータブルに作ってしまえば、移植のコストを抑えることができるかもしれません。 ちなみにDBの負荷が激しい場合は、キャッシュサーバを検討することになります。 データはDBに入るまでは流れとしてとらえる必要があるので、(ネットワークやIOなどの)流量に着目して検討すると良いと思います。