ブログ

2024年
12月08日
初めて対応したインフラの改修の流れ
React Flow
2024年
12月07日
今やりたいことについて考える
もっとフロントエンドの領域の知識を深くして、専門領域とする。インフラ周りも理解できるようにする。
やりたいこと。 1.ReactおよびNext.jsについてもっと学んで思想を掴みたい。 2.UI/UXについて学んでより良い画面や機能を作りたい。 3.AWSをもっと触って、実務で対応できる力をつける。 4.terraformを活用してAWSのリソースを管理したい。
やること。 1.オライリー社が出しているReactの本を読んで根本的な概念を学んでまとめる。いろんな記事を見て、まとめていく。 2.UI/UXの知識をつけるところから始める。付けた知識をこのサイトに反映させていく。 3.AWSのいろんなサービスを自分で要件を決めて触ってみる。触ったら、このサイトなどにまとめていく。 4.本読んで学習して、触っていく。
2024年
12月01日
就寝前の1日振り返り
前月の AWS 請求書は、新しい月の初めに確定します。その後まもなく、通常はその月の 3 日目から 5 日目までの間に、デフォルトの支払い方法に請求
https://repost.aws/ja/knowledge-center/monthly-aws-billing
null_resourceはtriggersが新しい値を含めていないと実行されない。ECRのImageが更新されないのはこれが原因だった
Lambdaに環境変数を渡すには複数方法があるが、1つとして`export TF_VAR=`を設定してvariablesの値を管理することで、terraform applyの時にlambdaのenviromentに変数を渡すことができる。 他に渡せる渡し方がないか模索する必要がある。もっとセキュリティ安全なやり方を模索 セッションパラメーターを利用するといいかも。
これ後で調べる
原因2: イメージタグが上書きされている ECRで同じタグ（例: latest）を使って新しいイメージをプッシュした場合、Lambdaは古いキャッシュされたイメージを使用する可能性があります。
2024年
12月01日
AWS Lambdaを触ってみた
昨日の経験を活かして、handler関数に処理を記述してLambda関数の実行ができた。 決まった定数を出力することや汎用的なロジックはchatgptを使うことですぐにかけるので時間をかけなくていいなと思った。 環境変数がない場合に、エラーとして出力するのが気付きやすそうだった。 dockerのimageを追加するたびにterraformでlambda関数を削除と作成するのがめんどくさかった。 正しい使い方をできていないと思うので、そこら辺はまた今度調べる。 dockerのbuild時の値が影響して、関数の実行することができていない?みたいだったのでここら辺はまだわかってないところ。 ひとまず、event bridgeとlambdaを用いてslackに定期実行できるようになったのでよかった。
2024年
11月30日
就寝前の1日振り返り
今日はLambdaとAPI Gatewayを用いて、APIを作ってみようと色々模索していた。 従来のやり方に似せてECRでImageを管理してLambdaでそのImageを使う方法が良いのではと思い、色々調べたり試した。 だが、全然うまくいかなかったので後日再挑戦しようと思う。前に同僚にServerless Frameworkを使えばいいと聞いたので、それを今度は試してみようと思う。 1日の5,6時間使っても、ECRで管理しつつLambdaでapiを実行させるやり方が見つけられなかった。 なぜうまくいかないのかも、Cloud Watchに吐かれているログを見てもわからなかった。 Lambdaで適切にログも出力できていなかったんだと思う。 API Gatewayの設定も理解した上で利用できていなかった。 LambdaとAPI Gatewayの構成でAPIを作成しようとした時に、サーバー(express.jsなど)をまずは作るという思考がよくなっかった。 関数(handler)を1つ定義してImageをプッシュしてLambdaを実行すれば関数の実行はうまくいった。 その思考で特定の処理を実行するようにするか、Serverless Frameworkを使ってAPIを作るようにする。 今のところ、この2つの手段ができるということがわかったのが今日の収穫。 今日はひたすら手を動かして、なんとなく進めていたので遠回りを色々したと思う。 次はきちんと調べて、やりたいことに対して基本的な知識を入れてから作業に入ろうと思う。
2024年
11月26日
就寝前の1日振り返り
今日の学び。
パフォーマンスを改善するには、以下の手順を必ず行う。計測、仮説、検証、改善。 推測で仮説をしたり、いきなり改善に手を出してしまうと適切に対応することができない。できてもまぐれでできるだけ。 計測をきちんと行う。 DBだったら、コネクションプールやCPU使用率など計測している場所を見てみる。 計測できていない場所が原因だと、何も知ることができないので何を計測するのか、そもそも計測できるかを理解しておくことが大切。 アプリケーションだとプロファイラを用いてプログラムの実行速度や使用リソースの収集を行うことが良さそう。rubyなどはgemを用いて計測できそう。 使ってる言語で調べてプロファイラを選択する。ruby-profはプロファイルを行うgem？だと思うので今度試してみる。 仮説は知識量がものを言うので、いろんなことを調べていろんな観点から計測結果を観れると良い。
Amplifyのリダイレクト処理で特定の階層全てにリダイレクト処理を含めたい場合は少し特殊なことをする。 公式でやり方を見つけた。amplifyは特定の条件(パス以外)でリダイレクトさせることを指定でいないのが辛い。
ALBのリスナールールで特定のパスの向き先を指定する際は「/」と「/*」を理解して指定する必要がある。 最近、AWSのUIが少し変わって、リスナールールの優先度をまとめて変更できるような機能が出てきて一括で更新できるのが便利だと思った。(前からある？)
2024年
11月21日
今日気がついたこと
最近DDDを用いたAPIの開発をやっていて気がついたことがある。(結構当たり前のこと) フロントエンドもurl設計やコンポーネント設計、ディレクトリ設計を開発のフローに組み込むのが良いのではないか。 DDDではコーディングルールの大枠が決まっており、ある程度どこに何を書くのかが迷いづらい。 フロントエンドはDDDほどのコーディングの時のルールみたいなものが独自に確立していない。(現時点での自分の知識では。) だから、バックエンドやWebアプリで人気のあるアーキテクチャや開発手法を参考にフロントエンドを開発していく記事を目にしたことがある。 BFFもそれに近いかも。 そう考えると、フロント独自の開発サイクルの中でフロントエンドのみで完結するDDDに変わるものが存在していれば、それをもとにシニア、ジュニアのエンジニア関係なく開発を行なっていけるのではないか。
コードを綺麗に保ちつつ開発スピードを上げていくには、 自分のタイピング速度だったり、そういう開発のサイクルの見直すことが大切かな。 開発サイクルの中に2回のレビューのタイミング(設計とプルリクエスト)を設ける方がプルリクエストだけレビューするよりも実装者もレビュワーも作業のスピードが変わってきそう。
2024年
11月20日
CIDRをきちんと分ける
CIDRをきちんと分けることで、階層的かつ効率的なIPアドレス設計を行うことができる。
ネットワーク計算してくれるサイトなどを探すことで、効率的に設計を行える。
ネットマスクが/20だと4000くらいのIPアドレス範囲になる。/19だと8100くらいのIPアドレス範囲になる。 /24だと256のIPアドレス 範囲となる。256だけだと、運用していくとすぐに全て使い切ってしまいそうになる気がする。 /20や/19くらいが現状良いと考えてる。根拠を見つけるのはまた今度。
新たにサブネットを作るのが意識してやったことが無かったので、イメージができてなかった。 実際にやってみると、CIDRをきちんと分けること、ルートテーブルに割り当てること、プライベートサブネットならNAT Gateway(or vpce)、パブリックサブネットならInternet Gatewayにつなげることを考えるとうまくいく。
既存のサービスを分離する時には、パブリックサブネットとプライベートサブネットはどちらも分離した方が、 なぜ分離しなかったのかを未来の自分や他のエンジニアが考えなくて済む。
データベースに存在するユーザーはアクセスできる権限が必要最低限にするのがよい。 マスターユーザー(スーパーユーザー)でログインして操作できるように運用していると、 そのアクセス用のパスワードが流出してしまった場合に様々なことを悪意のある人ができてしまうのでなるべくマスターユーザーでアクセスしない。
スナップショットで復元したDBに存在するユーザーはパスワードは変えておいた方が良いと思う。 その際にDBのSGは必要なサービスからのアクセスだけ許可する。
2024年
11月19日
マスキングするsql
名前、パスワード、メールのマスキング
UPDATE your_table SET name = 'masked_' || id, email = CONCAT( md5(random()::text || id::text), '@example.com' ), password = md5(random()::text)
ランダムなUUIDを利用する場合
UPDATE your_table SET name = 'masked_' || id, email = gen_random_uuid()::text || '@example.com', password = md5(random()::text) WHERE condition;
name: 元のidを利用して「masked_1」のような一意な文字列を作成しています。idがない場合はランダムな数値やUUIDを生成する方法も検討できます。
email: md5()関数を用いて、一意性を保つハッシュ値を生成し、任意の固定ドメイン（例: @example.com）と組み合わせてユニークなメールアドレスを生成しています。
password: ランダムな値をハッシュ化することで、元の値と無関係なランダムな文字列に置き換えています。
gen_random_uuid(): 一意なUUIDを生成する関数（pgcrypto拡張が必要）。 CREATE EXTENSION IF NOT EXISTS pgcrypto;で有効化できます。
2024年
11月18日
就寝前の1日振り返り
データベースを作成したら、アクセス権限を最小にする。 アクセスのためのパスワードやホストの情報が万が一流出してしまった場合を考えて、データベースに作成するユーザーの権限を必要な権限だけにしておく。 必要なアクション: CRUD処理、マイグレーション(テーブル作成、テーブル削除(ドロップ)など) 以下の記事などを参考に今度、マイグレーションまで行えるROLEを作れるようにする
IAMユーザーに権限を与えるときはポリシー名や権限の内容をAWSサービスごとなど分割しておく。そうしないと、どんな時に何のアクションが必要だから権限を付与したのかがわからなくなってしまう。
いろんな領域のユーザー権限に関してまだまだやり方を見つけられていないのが課題。
参照
2024年
11月16日
SEOを高めるための調査
タイトルタグ
<title> ページの内容 - サイト名 </title>
のように構成するとよい。キーワードを詰め込みすぎず、なるべく簡素にページの内容を説明する。
2024年
11月15日
就寝前の1日振り返り
IAMは新しくする。AWSで新たなリソースを作るときはIAMユーザーを新しくする。IAMユーザーに付与するポリシーは適切な区別をしてポリシーを管理する必要がありそう。 既存のIAMユーザーのポリシーはいろんなAWSリソースの権限を持つポリシーを付与されており、何のアクションをしたいから付与したのかがわからなくなる。 例えば、ecsのための権限、ecrのための権限、codedeployのための権限などで区切るのが良いのではないかと考えている。 どういう区切り方がよいのかは今後、学ぶ必要がある。 必要以上の権限を与えないという考え方でIAMユーザーに権限を与えるなら、この分野のノウハウはすごく必要になる。
gitkeepしてるファイルに注意する。gitkeepファイルは空ディレクトリをgitで管理したい時に使う。 githubに空ディレクトリがあって、空ディレクトリがgitignoreされている場合は、先に空ディレクトリがgithubにpushされているはず。 そのため、gitignoreされていることに気づかず二からディレクトリがundefinedのエラーに遭遇してすぐに解決できない。
拡張子に注意。test.json.stagingの拡張子だと、jsonファイルとして認識してくれないので、invalidな形式で値を定義していてもvscodeでエラーの判定を出してくれない。 気づくにはtest.jsonとしてエラーがあるかを確認する必要があり、それを行わないと気づくのが難しい。
2024年
10月30日
就寝前の1日振り返り
今日もバックエンド分離作業の調査を行なっていた。コスト周りの調査を行なっていた。既存の本番とステージングでかかっているお金を調査したり、分離した後にかかりそうな金額を算出していた。 思っているよりもECSとRDSの金額が高いと思うので、そこはスケールダウンさせたりしながら使いたいなという結論になってる。 これをあとはどうやってまとめて共有するかは明日行う。ここらへんを気軽に相談できる先輩エンジニアがいないのでストレスに感じた。 仕事中に外部の方との1on1を行う機会があり、タイミング良くその問題を相談できたのはよかった。 改めてインフラの調査はもっと経験していかないといけないなと感じた。
早めに仕事を退勤して、若手クラウドエンジニアが登壇していたセミナーに参加した。 そこで話を聞いて印象に残っていたのは、クラウドエンジニアが成長するには環境要因が大きいだろうなと感じた。 会社の雰囲気、失敗を恐れないこと、Bias for action(スピード重視で、まず行動する)などは組織文化が根付いており、そのためのサポートもあるようだ。 チャレンジする組織→人が成長する→ビジネスを牽引→モチベーション向上→チャレンジする組織のサイクルを回し続けることが重要だということもおっしゃっていた。 IaCの構築をしておくことで、その後のインフラ管理が行いやすくなる。そのため実務でも導入を行っていきたいと考える。 汎用的な作業に時間はかからず、本来見なければいけない場所に時間をかけることができる。 CloudFormationを使っているようだったが、自分はTerraformを学んでいこうと思う。 そして、AWSの資格もそろそろ取得してさらに知識を増やしていきたい気持ちが高まった。
2024年
10月29日
就寝前の1日振り返り
今日もバックエンドの分離作業のためにAWSでの作業内容の洗い出しとアーキテクチャ図を書いて先輩エンジニアに軽く相談した。 インフラを構成するときに、サービスがどれくらいの利用者で売り上げを目指しているから、インフラにこれくらいの費用を使うことができるという観点が必要だと教えていただいた。 まだまだ、インフラの構成するときの選択肢として使ったことがないけどインフラの費用が抑えられるという選択肢を選んで提案できるようにしなければいないと感じた。 既存のインフラ構成を複製することが、良い設計ではない。
同い年のエンジニアがembeddingとOpenAIを用いた検索機能を個人開発でやっているのを教えてもらった。自分も早くそれらの領域を使ってみたいと思い開発のモチベーションが上がっている。
2024年
10月28日
就寝前の1日振り返り
今日はバックエンドの分離作業のためにAWSでの作業内容の洗い出しとアーキテクチャ図を少し書いた。 インフラの構成を変えるので、コスト面についてもきちんと共有して進めていかなければいけないと指摘されて気づいた。 AWS関連の作業は実務では初めてと言ってもいいので、色々辿々しいがスピード感を持ってPDCAを回して失敗してもいいから進めていく。
同業者と連携してAPIを活用して統合させていくのは難しいなと感じている。同じモデルでも異なるプロパティや仕様が少し異なるだけでも考慮しなければいけないことは増えるので、遠回りしてしまうかもしれない。 遠回りは無駄ではないが本来のプロダクトがあるべき姿や成し遂げたいゴールに向かってきちんと道を作って歩いていけるようにする。