2023-12-04
問い合わせの発生原因がDBというのは、本日対応した〇〇がはじめてでした。DBを疑うという考え方がこれまでなかったため、新しい目線を得ることができました。今後はDBも問い合わせ発生原因の1つとして疑っていきたいと思います。
2023-12-06
ソフトウェア開発のアーキテクチャパターンの一つである「BFF」(Backend For Frontend)について知ることができました。
- このアプローチでは、特定のUIやフロントエンドに対してカスタマイズされたバックエンドサービスを提供する
- BFFは、特定のアプリケーション(モバイルアプリやウェブアプリなど)に合わせて設計されたAPIを提供する。これにより、フロントエンド開発者はバックエンドの複雑さを抽象化し、より効率的にアプリケーションを構築することができる
- 特定のUI向けに最適化されたAPIは、必要なデータのみをフロントエンドに送信する。これにより、通信のオーバーヘッドを減らし、アプリケーションのパフォーマンスを向上させる
- BFFを使用すると、バックエンドとフロントエンド間の通信がシンプルになり、セキュリティが向上する。また、APIの変更がフロントエンドに与える影響を局所化できるため、メンテナンスが容易になる
- 各アプリケーションは独自のBFFを持つことができるため、異なるフロントエンドチームが互いに干渉することなく作業できる
このアーキテクチャは、特に大規模なアプリケーションやマイクロサービスアーキテクチャを採用している場合に有効。ただし、各フロントエンドに対して専用のBFFを維持する必要があるため、追加の開発と管理の負担が生じることもある。
2023-12-07
Pythonの標準ライブラリであるloggingモジュールについて、詳細を調べました。
前提として、loggingモジュールを使用することで、デバッグ情報, 警告, エラーメッセージなど、様々な重要度のメッセージを出力, 保存, 外部システムへの送信を行うことができる。
ログレベルとしては、主に下記のようなものがある
- DEBUG:デバッグのための詳細情報
- INFO:通常の動作を確認するための情報
- WARNING:予期しないことが発生した、または将来的な問題が発生する可能性があることを示す情報
- ERROR:より重大な問題により、プログラムの一部が実行されなかったことを示す情報
- CRITICAL:非常に重大なエラーで、プログラムが動作を停止する可能性があることを示す情報
その他、loggingモジュールに関する用語とその意味
- Logger:ロギングの主要なオブジェクトで、アプリケーションからログメッセージを受け取る
- Handler:Loggerが受け取ったログメッセージを適切な出力先(コンソール、ファイル、ネットワークなど)に送信する
- Formatter:ログメッセージの出力形式を決定する
- Filter:どのログメッセージがログ出力されるかを決定するための詳細な機能を提供する
2023-12-08
下記のような記法を知ることができました。
$eventMenu = $event[‘eventMenu’] ?? null;
- 配列$eventにeventMenuというキーが存在しており、かつそのキーに対応する値が空ではないと判定される値の場合は、$event[‘eventMenu’] を格納
- 配列$eventにeventMenuというキーが存在しない場合や、存在したとしても値が空と判定される値である場合は、nullを格納
2023-12-13
PHPのis_numeric関数が、数値文字列をtrue判定することをはじめて知りました。
関数名からして、数値型か否かを判定すると思い込んでいましたが、数値型だけではなく、数値文字列(”111″など)もtrue判定するとのことでした。
2023-12-15
AWSにおいて、サブネットに付与するネットワークACLのステートレスな挙動について理解することができました。
前提として
- ネットワークACLとは、サブネット単位での通信を制御するもの
- サブネットから外部ネットワークへの通信と外部ネットワークからサブネットへの通信の両方を制御する
- 特定のIPアドレスの範囲、プロトコル、ポート番号の3要素を用いて、許可あるいは拒否する通信のルールを決定する
- ネットワークACLはサブネットに適用されるため、そのサブネット内に存在する全てのリソースに影響を及ぼす
- サブネットから外部ネットワークへの通信の制御には、マルウェアによるデータ流出を防ぐ際などに役立つ
ステートレスな挙動について
- ネットワークACLでは、入力トラフィック(リクエスト)と出力トラフィック(レスポンス)に対するルールがそれぞれ独立している
- これにより、リクエストは入力ルールによって許可されたとしても、レスポンスは出力ルールによって許可されないという状況が発生する可能性がある。すなわち、リクエストは受け付けるが、レスポンスは返さず、通信が完了しないという状況が発生する可能性がある
- このようなことを踏まえると、ネットワークACLには、入力と出力に対する適切なルールを設定することが重要である。これにより、意図した通信だけを許可し、不要, 不審な通信は適切にブロックすることができる
サブネット内に存在するインスタンス毎に適用されるセキュリティグループは、ステートフルな挙動であり、すなわち入力トラフィック(リクエスト)が許可された場合は、それに対する出力トラフィック(レスポンス)は自動で許可されると思います。こことの違いは、しっかり理解しておきたいと思います。
2023-12-18
VPCエンドポイントを作成する利点について知ることができました。
- VPCエンドポイントを作成することで、VPC内のリソースがAWSサービスと通信する際に、インターネットを経由せず通信を行うことができる。
- 例えば、private subnetを起点にS3にデータをアップロードする場合、VPCエンドポイントを作成していないと、private subnet → NAT Gateway → internet gateway → 外部のネットワークを経由してS3の対象バケットへデータをアップロードする流れになるかと思います
- しかし、VPCエンドポイントを作成することで、private subnet → VPCエンドポイント → S3バケットという流れになり、外部のネットワークへのアクセスが不要になる
- これによりセキュリティのリスクが低減する
2023-12-20
github actionsからAWS等のクラウドを操作する際に用いられる「Open ID Connect」の機構やそれに伴う必要な設定および各設定の意味、加えてその他の周辺知識について、下記の記事より理解することができました。
https://zenn.dev/miyajan/articles/github-actions-support-openid-connect
https://zenn.dev/kou_pg_0131/articles/gh-actions-oidc-aws
2023-12-22
AWSのEBS(Elastic Block Store)の概要を知ることができました。
- EBSとは、EC2インスタンスに接続して使用される、EC2インスタンスで使用するデータを永続的に保存するストレージサービスのこと
- ブロックレベルのストレージで、データをブロック(小さなセグメント)として保存することで、高速なアクセスと柔軟な管理を実現する
- EBSが提供するストレージを「EBSボリューム」と言う
- EBSボリュームは、EC2インスタンスの一時的なストレージ(インスタンスストア)とは異なり、インスタンスのライフサイクルから独立している。これにより、EC2インスタンスを停止, 終了しても、EBSボリューム上のデータは保持されるため、長期間にわたるデータ保存に適している
- EC2インスタンス間でボリュームを簡単に移動させることが可能
- 複数のボリュームタイプを提供しており、それぞれ異なるパフォーマンス特性とコストを有する
- EBSボリュームのスナップショットを取ることで、その時点のデータ復元が可能
- EBSボリュームは要件に応じてサイズやパフォーマンスを動的に変更することが可能
- データは自動的に複数の物理ドライブにレプリケートされるため、高い可用性と耐久性を有する
2023-12-26
S3が提供しているライフサイクル機能について知ることができました。
ライフサイクル機能とは、不要になったオブジェクトやアクセスされていないオブジェクトの保管をコスト的に助ける機能のこと
自動データ移行
- ライフサイクルポリシーを使用して、オブジェクトを自動的に異なるストレージクラスに移動させることが可能
- 例えば、アクセス頻度が低下したオブジェクトをStandardからStandard-IAやOne Zone-IAに移動させることが可能
データの自動削除
- 特定の期間が経過したデータや特定のパターンに合致したデータを自動的に削除することが可能
- これにより、不要なデータの保持によるコストを削減することができる
異なるライフサイクルポリシーの適用
- S3のバージョン管理機能と統合されており、異なるバージョンのオブジェクトに対して異なるライフサイクルポリシーを適用することができる
- また、特定のプレフィックスやタグに基づいて、異なるライフサイクルポリシーを適用することができる
- これにより、様々なデータに対して異なる保管戦略を採用することができる
S3の主要なストレージクラスとその特徴は下記。様々な使用ケースに合わせて設計されている。
S3 Standard
- 用途:頻繁にアクセスされるデータ及び重要なデータの保存に適している
- 特徴:データは冗長して保存され、高い耐久性と可用性を提供する。リアルタイムに頻繁にアクセスされるデータの保存に適している。
S3 Standard-IA(IA = Infrequent Access)
- 用途:頻繁にアクセスされないが、必要に応じてすぐにアクセスできる必要があるデータの保存に適している
- 特徴:S3 Standardと同様の耐久性を提供する。S3 Standardと比較し、ストレージの単価が低く設定されている。そのため同じデータ量を保存する場合、S3 Standard-IAの方がコストが低くなる。一方で、データの読み出しや取得には追加料金が発生する。このような特徴により、結果的に、頻繁にアクセスされないデータに対してのコスト効率の良い選択肢を提供している。
S3 One Zone-IA
- 用途:重要ではない一時的なデータや、別の場所にバックアップが存在するデータの保存に適している
- 特徴:低単価でデータを保存できる。一方で、データは単一のAZ内にのみ保存される。
S3 Reduced Redundancy Storage(RPS)
- 用途:耐久性が若干低く、コストを削減したい場合に適している
- 特徴:現在は推奨されていない古いストレージクラス。現在は上記3つのストレージクラスが推奨されている。
2023-12-27
下記のような形でJSでformを作成してsubmitすることができることをはじめて知りました
$(‘
‘, {action: url, method: ‘post’, target: ‘_blank’}).append($(‘‘, {type: ‘hidden’, name: ‘student’, value: students}))
.appendTo(document.body)
.submit();