Noteに移動します

技術系はNoteのブログに移行しました

https://note.com/green_blue_sky/m/m45b1f2fbfbde

相対性理論の問題点

相対性理論は、20世紀初頭にアインシュタインによって提案され、数々の実験的な検証を経て成功を収めた、非常に成功した物理学の理論です。しかし、その一部には未解決の問題や課題が存在します。以下に、相対性理論に関連する主要な問題点や課題をいくつか示します。

1.重力と量子力学の統合:

相対性理論は重力を記述するための優れた理論であるが、重力と量子力学を統合する試みが進行中です。これは「量子重力理論」として知られており、宇宙の非常に小さなスケールや非常に高いエネルギーの領域での物理現象を説明するために必要です。一般相対性理論は、これらの領域では限界がある可能性があります。

2.暗黒物質と暗黒エネルギー: 

相対性理論は、宇宙全体の構造や進化を説明するために広く受け入れられていますが、宇宙の約95％が暗黒物質と暗黒エネルギーで構成されているとされ、これらの物質やエネルギーの正体は未だに解明されていません。相対性理論ではこれらを説明できないため、新しい理論が必要かもしれません。

3.特異点とブラックホール内部: 

一般相対性理論によれば、ブラックホールの中心には「特異点」と呼ばれる物理的な無限が存在するとされています。この特異点についての理論的な説明は未だに確立されておらず、物理学者たちはこの問題に対処するための理論を模索しています。

4.超光速粒子: 

相対性理論では、情報や物体は光速度以上で移動することはできないとされています。しかし、一部の理論や実験結果が、超光速粒子やタキオンといったものの存在を示唆しており、これらの粒子の振る舞いを説明する新たな理論の必要性があります。

これらは相対性理論の一部の課題や未解決の問題ですが、相対性理論は依然として物理学の基盤として非常に有用で、多くの実験的な検証に合格しています。将来の研究によって、これらの課題に対する新たな理論やアプローチが発展することでしょう。

質問と回答案02

質問 

【具体的な相談内容】

Python+FastAPI+UvicornでのAPIサーバーのレスポンスが良くなく、Uvicornやその他サーバー設定の変更により改善できないかサポートいただきたいです。

Python+FastAPI+Uvicornの経験のある方にお願いできますと幸いです。

【現在の設定やアクセス状況など】

下記のコマンドでuvicornを立ち上げています。

nohup uvicorn main:app --port=80 --host=0.0.0.0 --workers=9

（ネットでworkersの数値はコア数×2+1が適正という情報を見かけたのでそのようにしています）

APIリクエストは別サーバーのバッチ処理からのみなので、同時リクエストは常時8以下程度になるようコントロールしているのですが、遅い時にはAPIレスポンスに30秒ほどがかかっています。

同じ処理内容のpyファイルを実行すると毎回1秒前後でレスポンスが返ってくるので、uvicornもしくはサーバー側の設定に問題があるものと考えています。

【サーバー環境】

エックスサーバーVPS（vCPU4コア・メモリ4GB）

OS：Ubuntu 20.04

Python 3.8.10

回答

FastAPIとUvicornを使用したAPIサーバーのレスポンスが遅い問題を解決するためのアドバイスを提供します。以下のステップを試してみてください。

1.Uvicorn Workersの調整:

--workersフラグを調整することは、サーバーのパフォーマンスに影響を与えることがあります。一般的なガイドラインは、コア数×2+1ですが、この値はサーバーのスペックや負荷によって異なります。試しにワーカーの数を増減させて、最適な設定を見つけてみてください。たとえば、もし4コアのCPUを持っている場合、ワーカーの数を9から8に減らすことも考えられます。

nohup uvicorn main:app --port=80 --host=0.0.0.0 --workers=8

2.ASGIサーバーの変更:

UvicornはASGIサーバーの一つですが、他にも多くのASGIサーバーがあります。一部のプロジェクトでは、Uvicornよりも性能が良いとされるサーバーもあります。代替のASGIサーバーを試してみることを検討してください。例えば、HypercornやDaphneを試すことができます。

3.非同期コードの最適化:

FastAPIとUvicornは非同期処理に対応しており、遅いレスポンスの原因が非同期処理の最適化にあるかもしれません。コード内で非同期処理を効果的に利用しているか確認し、遅延を引き起こす部分を最適化してみてください。

4.リクエスト処理のプロファイリング:

レスポンスが遅い場合、どの部分が遅いのかを特定するためにリクエスト処理をプロファイリングすることが役立つことがあります。PythonのcProfileモジュールやプロファイリングツールを使用して、処理時間のかかる部分を特定し、最適化の手がかりを得ることができます。

5.サーバーリソースのモニタリング:

サーバーのリソース使用状況（CPU、メモリ、ディスクIOなど）を監視し、問題がリソース不足に起因している可能性を確認してください。リソースが不足している場合は、サーバーのスペックをアップグレードするか、アプリケーションのリソース使用効率を向上させるために最適化を行う必要があります。

6.キャッシュの導入:

レスポンスの一部が頻繁に変更されない場合、キャッシュを導入してレスポンスの返却を高速化することができます。FastAPIはキャッシュライブラリをサポートしています。

7.データベースの最適化:

データベースクエリがボトルネックになる場合、データベースクエリの最適化を検討してみてください。インデックスの追加やクエリのチューニングなどが役立つかもしれません。

これらのステップを試して、APIサーバーのパフォーマンスを向上させる手助けとなるでしょう。問題が解決しない場合は、詳細なプロファイリングやロギングを行い、具体的な問題点を特定することが重要です。

回答の追加

提供された情報から、APIサーバーが同時接続数が多くなる理由は明確にはわかりませんが、いくつかの一般的な理由が考えられます。同時接続数が多い場合、サーバーのリソースや処理能力に関連する問題が影響を及ぼす可能性があります。以下は考えられる理由です：

1.バッチ処理の要求が多い:

APIリクエストが別のバッチ処理から送信されていると記述されています。もしバッチ処理が瞬間的に多数のリクエストをサーバーに送信している場合、同時接続数が急増することがあります。

2.処理時間の長いリクエスト:

APIのリクエストによって、処理に時間がかかる場合、リクエストが待機状態になり、同時接続数が増加する可能性があります。この場合、非同期処理を活用してリクエストを非ブロッキングにすることで、同時接続数の制御が改善できます。

3.リクエストのポリングや長時間の接続:

バッチ処理がサーバーに対して長時間の接続を保持し、ポリングを行っている場合、同時接続数が増加することがあります。この場合、WebSocketなどのプッシュ通知の仕組みを検討して、リアルタイム通信を改善できるかもしれません。

4.サーバーのリソース不足:

サーバーのスペック（CPU、メモリ）が同時接続数を処理するには不足している可能性があります。サーバーのスペックをアップグレードすることで、同時接続数を増やすことができます。

5.スロークライアントやネットワークの問題:

一部のクライアントがリクエストを送信し続けることがあり、これが同時接続数を増やす要因となることがあります。また、ネットワークの問題や遅延も同時接続数に影響を及ぼす可能性があります。

同時接続数が問題となる場合、まずは何が同時接続数を増加させているのかを特定し、その要因に対処する必要があります。リクエストのパターンや処理時間を監視し、適切な対策を講じることで、同時接続数の制御とサーバーパフォーマンスの向上が可能です。

質問と回答案01

質問

 【教えてもらいたいこと】

プログラミング/インフラ・クラウド, AWS, Docker

【利用目的】

技術的な質問・相談, ポートフォリオ添削, 個人開発相談

【具体的な相談内容】

現在、ポートフォリオが形になり始め、一旦、AWSへアプリをデプロイしようとしています。

以下の参考サイト通りに4回ほどデプロイに挑戦してみましたが、エラーに見舞われ、自分なりに考えて修正等を試みたのですが、それでも一向にエラーが解消できずにいます。

【参考にしたサイト】

https://zenn.dev/prune/books/28c2d690e11e45

【アプリ仕様】

・React

・RailsAPI

・docker-compose

・Docker

・S3

・Fargate

【お願いしたいこと】

・Fargateを使用してアプリをデプロイしたい。

　→現在の内容で、「どの部分が誤っているのか」ご指摘頂きたいです。

・更に、欲を言えばcircleCIを導入したい。

・デプロイに関する技術や知識をご指導いただきたい。

【最後に】

アプリケーションを作成し始め、半年以上が経過しました。今まで自分で調べてなんとかやってこれましたが、AWSの複雑さに翻弄されています。

当方、初心者も初心者ですが、何卒ご指南頂きたく、どうぞよろしくお願いいたします。

回答案

まず、Fargateを使用してReactとRailsAPIのアプリケーションをAWSにデプロイし、さらにCircleCIを導入する際のアドバイスを提供します。AWSのデプロイに関するエラーの解決をサポートするために、以下のステップを確認してみてください。

AWSアカウントの設定:

AWSのアカウントを正しく設定していますか？必要なアクセス許可があることを確認しましょう。

AWS CLIの設定:

AWS CLIが正しく設定されていることを確認し、必要な情報（リージョン、アクセスキー、シークレットキー）が正確であることを確認してください。

Docker Composeの設定:

Docker Composeファイルが正しく設定されていることを確認してください。各サービスの設定が適切であるか確認しましょう。

Dockerイメージのビルド:

Dockerイメージを正しくビルドできているか確認し、必要なイメージがローカルに存在することを確認しましょう。

S3バケットの設定:

S3バケットが適切に設定され、アプリケーションでのアクセス許可が正しく構成されていることを確認してください。

Fargateタスクの設定:

Fargateタスク定義が正しく構成され、必要なコンテナイメージが指定されていることを確認しましょう。

セキュリティグループとVPCの設定:

Fargateタスクが適切なセキュリティグループおよびVPCに関連付けられていることを確認してください。

エラーログの確認:

AWSのエラーメッセージやログを確認し、具体的なエラーの内容を特定しましょう。それに基づいて問題を解決できるかもしれません。

CircleCIの導入:

CircleCIを導入する際には、リポジトリ内に.circleciディレクトリを作成し、設定ファイルを追加します。CircleCIのドキュメントを参考にして設定を行いましょう。

デプロイに関する知識の向上:

AWSやDocker、Fargate、CircleCIなどのテクノロジーに関する知識を向上させるために、公式ドキュメントやオンラインリソースを積極的に利用しましょう。

問題が特定のステップで発生している場合、具体的なエラーメッセージやログを共有することで、より具体的なアシストができます。また、特定の問題に関する質問があれば、随時お知らせいただければ幸いです。

X(旧Twitter)の利用規約の変更

X(旧Twitter)の利用規約の変更が9月29により始まる

要点をまとめる

• ユーザーアカウントのセキュリティに関する責任
• 強力なパスワードの使用
• 不遵守に起因する損失への責任排除
• 本サービスの利用許可
• ソフトウェアの非独占的なライセンス
• Xの名称や商標の使用権限なし
• 本サービスの悪用に関する規定
• 不正アクセスや技術的制限の回避禁止
• スパムやサービスへの負荷をかける行為禁止
• 本規約の終了
• アカウント削除による法的契約終了
• アカウントの削除方法の案内
• 当社がアカウントを削除する条件
• 免責事項と責任の制限
• 本サービスの「現状のまま」提供
• Xエンティティによる保証および責任排除
• 間接損害への責任制限
• 全般
• 規約の改訂と通知方法
• 準拠法と管轄裁判所
• 英語版規約が優先
• 無効な規定の制限と放棄の非適用
• 連絡先情報提供

発効日: 2023年9月29日

写真や動画など投稿した内容については非独占的ライセンスとなり
有料の利用者はダウンロードし二次加工を容認している

インフラなどの費用負担など、かなりXの経営を圧迫していることがうかがえる
ただ、このようにしていけば、写真や動画について、Xを利用することは減りそうだ
また広告が増えると、見たくない人もいるが、ブロックできず、ミュートだけ
今後急速に利用者が減りそうだ

青い鳥を失った企業、将来はどうなるのでしょう
見守りましょう