apache, ajp, tomcat

  1. リバースプロキシとはなんですか?

    リバースプロキシ(Reverse Proxy)は、クライアントと複数のバックエンドサーバーとの間に配置されるサーバーの一種です。通常のプロキシサーバーとは異なり、リバースプロキシはクライアントから受け取ったリクエストをバックエンドサーバーに転送し、バックエンドサーバーからのレスポンスをクライアントに返す役割を果たします。

    以下はリバースプロキシの主な特徴と用途です:

    • クライアントとバックエンドサーバーの間に挟む役割: リバースプロキシはクライアントと複数のバックエンドサーバー(通常はウェブサーバー、アプリケーションサーバー、またはコンテンツ配信サーバー)の間に配置されます。クライアントはリバースプロキシを通じて通信し、リバースプロキシが適切なバックエンドサーバーにリクエストを転送します。

    • 負荷分散: リバースプロキシは負荷分散を実現するために使用できます。クライアントのリクエストは複数のバックエンドサーバーに均等に分散され、トラフィックの負荷を分散することができます。これにより、高い可用性とスケーラビリティが実現されます。

    • セキュリティ: リバースプロキシはセキュリティの境界を形成し、バックエンドサーバーを直接公開しないため、セキュリティの強化に役立ちます。クライアントからのリクエストを検査し、不正なトラフィックや攻撃を検出・ブロックすることができます。

    • SSLオフロード: リバースプロキシはSSL/TLS暗号化を処理することができ、バックエンドサーバーからの負荷を軽減します。これにより、バックエンドサーバーは暗号化解除されたデータを処理する必要がなくなり、パフォーマンスが向上します。

    • キャッシング: リバースプロキシは一時的にデータをキャッシュすることができ、再リクエスト時にキャッシュからデータを提供することができます。これにより、静的コンテンツの高速な提供や、負荷軽減が可能です。

    リバースプロキシは、ウェブサービスやアプリケーションの運用において重要な役割を果たし、セキュリティ、パフォーマンス、可用性の向上に寄与します。代表的なリバースプロキシソフトウェアにはApache HTTP Server、Nginx、HAProxyなどがあります。

  2. ApacheAJPTomcatStrutsの関係性をそれぞれ説明してください

「基礎からの新しいストレージ入門」読書会2 (2023/09/11 20:30-22:00) p61-p89

めも ベアメタルサーバ OSはいってないまっさらな物理HDD(SSDもいいの?)のこと

2種類あるよ ブロックストレージ

ファイルストレージ

マウントしたら使える

LVM:?????

ディスカバリ→接続的な意味合い

IQN:謎 LUN:謎

VMとは?あらため → KVM(しょうみわからん)

NTFSNFS: unix SMB: microsoft

Hypervisor→しょうみよく理解できてない

通常インデックス作成時には、テーブルに対して書き込みロック
→ マルチテナントの場合は?

INDEX CONCURRENTLY

PostgreSQLはテーブルを2回スキャンしなければなりません。 さらに、潜在的にそのインデックスを使用する可能性がある、実行中のすべてのトランザクションが終わるまで待機しなければなりません。 したがって、この方式は通常の方式よりも総作業時間がかかり、また、完了するまでの時間が非常に長くなります。 しかし、インデックス作成中に通常の操作を行い続けることができますので、この方式は運用環境での新規インデックス作成に有用です。 もちろん、インデックス作成によりCPUや入出力に負荷がかかりますので、他の操作が低速になる可能性があります。

絶対にテーブル全体インデックス張り直しになるの?
例えば、TENANT_ID, STATUS の複合インデックスを作成したテーブルにINSERTした場合、
TREEの一部に追加されるだけのイメージだが、他テナントに影響はありますのん?


複数検索条件(A, B, C)があるとき...

  • idx_tenant_id_A: (tenant_id, A)
  • idx_tenant_id_B: (tenant_id, B)
  • idx_tenant_id_C: (tenant_id, C)

のインデックスを作成すると?

SELECT * FROM table_name WHERE TENANT_ID = 1 AND A = "A" AND C = "C"

みたいなクエリはどうなる?


  • テーブル内のデータ量が多く、少量のレコードを検索する場合
    • WHERE句の条件、結合の条件、ORDER BY句の条件として頻繁に利用する

認証についての知識がほぼゼロなので... #01

認証についての知識がほぼゼロだったので触る

現場でJWTという認証方式が採用されたので、ちょいとお勉強しておく

ざっくり

トークンベースの認証とは、ユーザーが自分のアイデンティティを確認し、代わりに一意のアクセストークンを受け取ることを可能にするプロトコルです。トークンの存続期間中、ユーザーはトークンが発行されたWebサイトやアプリにアクセスできます。同じトークンで保護されたWebページ/アプリ/リソースに再度アクセスするたびに、資格情報を再入力する必要はありません。

毎回、IDパスワードで認証する必要はありませんよ〜と

なんか検索してると「JWT 認証 使うな」とかでてくるが、
正直認証まわりの知識がゼロに近いので、メリットデメリットがよくわからない
ので一旦JWTを勉強する。
(なんかしらの脆弱性とかがあるのか?わからない...

とりあえずのざっくりイメージ

認証

  1. id / パスワードを受け取る
  2. id / パスワードを検証する
  3. アクセストークン / リフレッシュトークンを生成して返却 jwtのライブラリで生成
/**
 * Synchronously sign the given payload into a JSON Web Token string
 * payload - Payload to sign, could be an literal, buffer or string
 * secretOrPrivateKey - Either the secret for HMAC algorithms, or the PEM encoded private key for RSA and ECDSA.
 * [options] - Options for the signature
 * returns - The JSON Web Token string
 */
export function sign(
    payload: string | Buffer | object, // Claim??
    secretOrPrivateKey: Secret, // 秘密キー
    options?: SignOptions,  // なんやかんやのオプション
): string;

次回接続時

  1. アクセストークン / リフレッシュトークンを受け取る
  2. アクセストークン / リフレッシュトークンを検証する
    なんやかんやするらしい
/**
 * Synchronously verify given token using a secret or a public key to get a decoded token
 * token - JWT string to verify
 * secretOrPublicKey - Either the secret for HMAC algorithms, or the PEM encoded public key for RSA and ECDSA.
 * [options] - Options for the verification
 * returns - The decoded token.
 */
export function verify(token: string, secretOrPublicKey: Secret, options: VerifyOptions & { complete: true }): Jwt | string;
export function verify(token: string, secretOrPublicKey: Secret, options?: VerifyOptions): JwtPayload | string;

デコードされたものが返却される、この時返されるのが、生成時に使用したpayload: string | Buffer | object, // Claim??

3.アクセストークンが期限切れの場合、リフレッシュトークンを検証するらしい(この辺はまた後で調べる必要ありそう

4.なんやかんや新しく生成されたトークンを返却する

アクセストークンが期限切れの場合

アクセストークン / リフレッシュトークンを再生成する

アクセストークンが期限切れではない場合

受け取ったアクセストークン / リフレッシュトークンをそのまま返却する

大まかな流れはこんなところ?

クライアント側の動きがよくわからないので、次はそのあたり