学習履歴一覧

183件中の 76-100件 を表示

良いコード/悪いコードで学ぶ設計入門 ~5章まで読了

やったこと 良いコード/悪いコードで学ぶ設計入門 ~5章まで読了 学んだこと 学び 「技術駆動命名」という言葉と、その意味を学んだ 「クラス単体で動作するよう設計する」という設計指針 言語機能を駆使して、不正利用できないようクラスを設計することが大事 (凝集性の観点から)むやみに共通化しない(common や util を作成しない) common や util クラスに実装するのは、低凝集な処理(横断的関心事)に限ること Tell, Don't Ask. 気付き 言語機能を駆使して、不正利用できないようクラスを設計することが大事 言い換えると、利用者側で変なことが出来ないよう、利用者側で出来ることを制限するよう設計する ようやく、言葉に出来た感 「インスタンス生成」も、一つのドメインロジック 「インスタンス生成」というドメインロジックが複数個所に散らばりかねない場合、factory メソッドパターンを使用して、インスタンス生成ロジックをカプセル化すると良い メソッドの引数が多い(特にprimitive型の引数が多い)箇所は、凝集度の高いクラスを設計できる可能性を示唆している メモ 技術ベースで行う命名を、「技術駆動命名」と呼ぶ 例) intValue01 のような変数名 「クラス単体で動作するよう設計する」という設計指針 電子レンジやキーボードなど、特に初期設定せずに使えるようなイメージ 不正利用できないような設計 クラス設計とは、インスタンス変数を不正状態に陥らせないための仕組みづくりと言っても過言ではない 「インスタンスを複数作って、インスタンス変数を使いまわさないようにする」のではなく、「インスタンス変数を使いまわされても、大丈夫なように設計する」ように インスタンス生成ロジックが増えてきたら、factory メソッドパターンを使用してインスタンス生成をカプセル化する (凝集性の観点から)むやみに共通化しない(common や util を作成しない) common や util クラスに実装するのは、低凝集な処理(横断的関心事)に限ること メソッドチェインは、凝集性・結合度の両観点から、不適切 複数のクラスが、一連のメソッドチェインに依存する(密結合) 「一連のメソッドチェインで実現する処理」が、いたる所に記述されかねない(低凝集) Tell, Don't Ask. メソッドチェインを分解せよ 分解した一連の処理をカプセル化し、一連の処理を提供できるメソッドのみ公開せよ

2023年03月21日(火)

1.0時間

単体テストの考え方/使い方 4章 読了

やったこと 単体テストの考え方/使い方 4章 読了 学んだこと 学び 退行保護に最大限備えるためには、テストの際にできるだけ多くのプロダクションコードを実行すること テストコードとプロダクションコードが密結合になっていると、false positive が発生しやすい false positiveの常態化は、テストが機能しなくなる原因となる、危険な状態 「退行保護」「リファクタリング耐性」「迅速なフィードバック」の三つは、トレードオフの関係 例) 「退行保護」「リファクタリング耐性」を最大限満たすと、速度が遅くなり、「迅速なフィードバック」は実現できない(E2Eテストなど) プロダクションコードの「what」ではなく「how」に目を向けているテストケースは、壊れやすい E2Eで検証するのは「アプリケーションにとって最も重要な機能、かつ、統合テストや単体テストで十分に検証できないテスト」のため 統合テストや単体テストで十分検証可能なテスト項目は、E2Eで検証する必要なし テストは、基本ブラックボックステストとして書く ブラックボックステストは、プロダクションコードに依存しないため、リファクタリングで壊れにくい(≒リファクタリングに耐性がある)ため ブラックボックステストで網羅出来ず、検証が必要な部分に限って、ホワイトボックステストを書く 気付き テストアラートの話は、運用やセキュリティに通ずるものがある 過剰なアラート(誤検知含む)は、オペレーターの注意を削ぐ 見逃しは、あってはならない プロダクションコードを呼び出す側の視点(つまりブラックボックステスト)でテストを書くと良い ホワイトボックス的なテストは、実装の詳細に強く依存するため、リファクタリングで破壊されやすい 「コンパイルエラーを伴わない false positiveは修正が困難」とは、言い換えると、コンパイルエラーや文法エラーを伴うテスト失敗は、修正しやすい => テストの失敗を、コンパイルエラーや文法エラーで検出できるようなテストは、壊れても修正しやすいテスト つまり、テストは大きく三種類に分かれる 壊れにくいテスト(≒リファクタリング程度では壊れないテスト) 壊れやすいけど、修正しやすいテスト(問題個所を、コンパイルエラーや文法エラーで検出できる) 壊れやすく、修正しにくいテスト(動きはするし、値も返すが、assert でコケるテスト。バグなのか、実装なのか区別が困難) メモ この章で扱う事 良い単体テストを構成する性質の大きな分類 理想的なテストについての定義 テスト・ピラミッドについて ブラックボックステストとホワイトボックステストの使い方 単体テスト 4つの柱 柱1 たくさんバグを検出できること(退行保護) 特に、ドメインロジックは、たくさんバグを見つけたい 反対に、UIやgetter/setter部分は、動くことの確認程度に抑える 必要なら、外部依存部分も含めて、想定通りに動くことをテストする 退行保護に最大限備えるためには、テストの際にできるだけ多くのプロダクションコードを実行すること 柱2 プロダクションコードのリファクタリングによって、テストが簡単には壊れないこと テストコードとプロダクションコードが密結合だと、リファクタリングによってテストコードが壊れやすい テストコードが実装に追いついていない(言い換えると、テストコードに問題がある)この状態を、書籍では false positive と呼んでいる false positive は、以下に示す単体テストの利点を潰してしまう テストを実行することで、プロダクションコードに埋め込まれた問題に気付くことが出来る false positive によるテスト失敗が常態化してしまい、プロダクションコードのミスに気付けなくなる テストを実行することで、「プロダクションコードが退行していないこと」を確認できる false positive によるテスト失敗が常態化してしまい、誰もテストを信用しなくなる 最悪、退行を防ぐ手段として「可能な限りコードを変更しないこと」という戦略が採択される 特に、コンパイルエラーを伴わない false positive は、バグとの区別が困難であり、調査に多くの労力が必要 柱3 迅速なフィードバック テストが短時間で完了できると、開発者は頻繁にテストを実施し、結果としてプロダクションコードのバグを早期に発見できる 柱4 保守しやすさ テストにて、何を検証しているのか把握しやすいこと テストの実施(実装できるまで準備する)容易さ テストピラミッドとは テストピラミッドにて E2E が最上位に位置する(≒最もテストケースが少ない)とされる理由 E2Eで検証するのは「アプリケーションにとって最も重要な機能、かつ、統合テストや単体テストで十分に検証できないテスト」のため E2Eにこそ、不要なテストケースを持ち込まないようにしたい ブラックボックステストとホワイトボックステスト ブラックボックステストはinとout を、ホワイトボックステストは、プロダクションコードの詳細を検証する ホワイトボックステストは、プロダクションコードに強く依存するため、リファクタリングによって壊れやすい 基本的に、テストはブラックボックステストとして書くことになる ブラックボックステストで網羅できない部分を、例外的にホワイトボックステストとして書く ... という運用になる まとめ 良い単体テストを構成する柱は、以下の4つ。 退行(regression、つまりバグ)に対する保護: たくさんバグを検出できるか テストにより、どれだけ多くのバグを検出できるか 「退行に対して保護されている」状態とは、テストによってより多くのバグを検出できる状態を示す リファクタリングへの耐性: リファクタリングした時に、テストが壊れにくいか false positive を押さえつつ、プロダクションコードをリファクタリングできるかを示す性質 false positive : プロダクションコードは正しいのに、失敗してしまうテスト - テスト失敗に慣れてしまい、テストの失敗に注意を払わなくなる - テストへの信頼が失われる 「リファクタリングへの耐性が高い」状態とは、バグのみを、バグとして警告するような状態を示す 迅速なフィードバック テストが完了する速度 保守容易性 テストにて、何を検証しているのかの把握しやすさ テストの実施(実装)容易さ 「退行保護」「リファクタリングへの耐性」「迅速なフィードバック」は、トレードオフの関係 最大限に備えることが出来るのは、二つまで テストが増えるほど、遅くなるよね? テストケースの作成にはブラックボックステストを、分析にはホワイトボックステストを用いる ブラックボックステストにより、実装の詳細に依存しなくなる

テスト

2023年03月20日(月)

2.0時間

書籍「アウトプット大全」3章 ~ 最後まで読了

やったこと 書籍「アウトプット大全」3章 ~ 最後まで読了 学んだこと 学び 「手で書く」というアウトプットは、記憶に残りやすい ドーパミンが、モチベーションを高め、アウトプットの質を高める 問題を解く(≒知識を使う)事で、記憶に残りやすい 暗記 3 : 問題集 7 程度の比率が良いとされる アウトプットしないインプットに意味はない ちょっとずつでもいいのでアウトプットしよう! 気付き インプット中に得た気づきを素早くアウトプットするためにも、付箋や書き込みは大事 脳の負荷を軽減するためにも、やるべきことは紙に書き出すと良い メモ 「手で書く」というアウトプットは、記憶に残りやすい タイピングは除く アンダーラインを引いたり、付箋を貼ったりすると、記憶に残りやすい インプット中に得た「気付き」を素早くアウトプットできる 脳は、最大3つまでしか同時処理できない やることが3つ以上ある場合は、メモに書き出そう! 日記や感想を書く場合、事前に時間を決めて書くと良い 最初から100% を目指さず、まずは20,30%程度でいいので全体を書ききることが大事 後で推敲すればよい 全体を大雑把にとらえるにはアナログツールが、詳細を詰める際にはデジタルツールが適している ドーパミンが、モチベーションを高め、アウトプットの質を高める ドーパミン分泌の一例 「少し難しい」程度の目標設定 締め切り駆動 客観的に評価可能な目標設定 有酸素運動を行う 目標を実現するためにやるべきこと 毎日目標を見直す 目標を公言する 定期的にフィードバックする 問題を解く(≒知識を使う)事で、記憶に残りやすい 暗記 3 : 問題集 7 程度の比率が良いとされる 暗記で得たインプットを、「問題集を解く」という行動でアウトプットするイメージ 結果を出すために 行動して、継続して、チャレンジを続けよう! 「人に教える」というアウトプットは、非常に効果的 アウトプットしないインプットに意味はない インプットの時間を減らしてでも、アウトプットしよう アウトプット例) 日記を書く 健康状態を記録する 読書感想を書く 情報発信する SNSに書く ブログ記事を書く 趣味に関する知識(特にニッチな知識)を書く

2023年03月20日(月)

2.0時間

Linux の仕組み 増量改訂版 4章 メモリ管理システム 読了

やったこと Linux の仕組み 増量改訂版 4章 メモリ管理システム 学び プロセスのメモリリークを観察したい場合は、 ps aux で表示できる %MEM 値の推移を見ると良い OOM Killer は非常に危険 対策しよう マシンスペック不足なら、メモリ増設や常駐プロセスの削減 プロセスのメモリリークを疑う 書籍の、「仮想記憶が無かったら?(意訳)」の解説より elf はエントリーメモリアドレス何かも決まっている事を学んだ 仮想アドレスを獲得しただけでは、メモリ使用量は増えない 仮想アドレス取得後、仮想アドレスを参照する処理を実行した時に初めて、OSは(仮想アドレスに対応する)物理アドレスを割り当てる 気付き メモリに関する情報は、個人的には free -h が読みやすい 「プログラムがメモリの参照を要求した時に初めて、物理アドレスを割り当てる」という挙動は、一種の遅延読み込み? 「必要な時に、必要な分だけメモリを割り当て、不要になったらさっさと開放する」という当たり前のことの重要性を再認識した メモリリークや、ページテーブルの肥大化に繋がる メモ メモリに関する情報は、 free , sar ,vmstat 等から取得できる free -h が読みやすい プロセス別のメモリ使用量を確認する場合は、 ps aux (特に u オプション)の推移を見る ユースケース : プロセスのメモリリークを観察する場合 OOM Killer は危険 メモリ不足時、OSが、動いているプロセスを強制終了してしまう ユーザからみると、突然プロセスが終了してしまう恐ろしい現象 書籍の、「仮想記憶が無かったら?(意訳)」の解説によると、仮想アドレスの仕組みが存在しない場合、マルチプロセス処理が非常に困難になる プログラマが、メモリ空間を厳密に管理しなければならない elf ( readelf コマンドから読み取ることが出来る ) 仮想アドレスを獲得しただけでは、メモリ使用量は増えない 「メモリ使用量は増えない」を言い換えると、「OSは、物理アドレスを割り当てない」 仮想アドレス取得後、仮想アドレスを参照する処理を実行した時に初めて、OSは(仮想アドレスに対応する)物理アドレスを割り当てる 内部では、ページフォールトが発生している 仮想アドレス獲得 仮想アドレス参照 (仮想アドレスに対応する物理アドレスが存在しないため)ページフォールト発生 仮想アドレスに対応する物理アドレスを割り当てる 仮想アドレス参照が可能に OSには、仮想アドレスを小さく保つ工夫が実装されている ページテーブルの階層化 ヒュージページ

Linux

2023年03月19日(日)

2.0時間

書籍「アウトプット大全」2章まで読了

やったこと 書籍「アウトプット大全」2章まで読了 学び 自己成長には、インプット量よりも、アウトプット量の方が重要 黄金比は、インプット 3 : アウトプット 7 インプットとアウトプットの最大の違いは「運動」 「声に出す」「書く」も運動 「何を話すか」が言語的コミュニケーション、「どう話すか」が非言語的コミュニケーション 人間の行動を変えるには、「気付き」が必須 雑談は、内容よりも回数が重要(ザイオンス効果) 自問自答するだけで、脳は活性化する 「褒める」「叱る」は、相手に気づきを与え、自己成長を促す絶好の機会 気付き 言語的、非言語的コミュニケーションを全て使用してコミュニケーションを図るのであれば、ジェスチャー、身だしなみ、声の強弱などが大事なのも理解できる 選択的注意を発生させ、学びを効率化するために、目標を自問自答する フィードバックは、相手に「気付き」を与える絶好の機会 相手に「気付き」を与えるような、示唆に富むフィードバックが、良いフィードバック 一歩間違えると、「自分の考えに誘導する(≒押し付ける)」ようなフィードバックになるかも。ここは注意点 「褒める」「叱る」もフィードバックの一種 相手に「気付き」を与えるような、示唆に富むフィードバック(ここでは「褒め」と「叱り」)が、良いフィードバック(大事なことなので二回言いました) メモ 1章 アウトプットの基本法則 アウトプットの定義は、「話す」「書く」「行動する」 自己成長には、インプット量よりも、アウトプット量の方が重要 インプットとアウトプットの最大の違いは「運動」 運動神経を使った記憶は、非常に忘れにくい 「声に出す」「書く」も運動 2週間で3回以上アウトプットしたことは、忘れにくくなる アウトプットのフィードバックを受けることで、更なる自己成長へ フィードバック : 見直し、反省、改善、方向修正、微調整、原因究明 うまくいったときも失敗した時も、その理由を考えよう 2章 科学に裏付けられた、伝わる話し方 アウトプットが苦手なら、まずは小さな雑談でもいいので「話す」ことから! ポジティブなアウトプットをガンガン増やそう! ネガティブなアウトプットは、誰も幸せにならない 「何を話すか」が言語的コミュニケーション、「どう話すか」が非言語的コミュニケーション 悪いニュースを伝える時は、クッション話法 「Yes But」話法 : 初めにポジティブな情報を伝える手法 「Yes And」話法 : 悪いニュースを、「こうすれば最高だな!」と、ニュアンスを変えて伝える 「Yes How」話法 : オープンクエスチョンを投げかけ、相手に考えさせる手法 雑談は、内容よりも回数が重要(ザイオンス効果) 自問自答するだけで、脳は活性化する 「褒める」「叱る」は、相手に気づきを与え、自己成長を促す絶好の機会 相手に気づきを与えるような「褒め」「叱り」は、とても良い

2023年03月15日(水)

1.5時間

単体テスト考え方/使い方 3章

やったこと 単体テスト考え方/使い方 3章 読了 学び テストは Arrange(準備)/Act(実行)/Assert(確認) の3フェーズ(以降AAA)で構成すること 単体テストのテストケースでは、必ず一つの振る舞いだけテストすること 実行フェーズや確認フェーズが複数ある場合、テストを分割すること 実行フェーズが複数行の場合は、カプセル化に失敗している可能性を示唆している 一方で、「実行フェーズを一行に収めること」を強制するべきではない if 文を含む単体テストはアンチパターン if 文が不要なくらい、単純なケースをテストするべき テストメソッドの名前に「should」を用いるのはアンチパターン テストメソッド名に希望や要望(つまりshould)を含めるべきではない 希望や要望ではなく、事実(~である、つまり「is」の方が適切 気付き コメントで AAA を明示するとよさそう 空行だと、準備フェーズを分けにくそう(Aの準備、Bの準備、AとBを使用してCの準備 ... など) 分かりやすい=>メソッド名と引数で、何をするメソッドか一発で理解できること 言い換えると、メソッドの実装コードを見なくても、実装をイメージできるようなメソッド名・引数となっていること テストメソッドの名付けに、実装に強く依存する(名前に、テスト対象のメソッド名を含むなど)ような厳格な命名規則を用いると、テストコードの保守性低下に繋がる パラメータ化する際は、「よくあるユースケースの正常系」「よくあるユースケースの異常系」「その他エッジケース」の3つぐらいがよさそう まとめ 必ず Arrange/Act/Assert の流れ! Act は1行! 複数行の場合、何らかの依存を疑うこと テスト対象システムを簡単に識別できるようにすること fixture を活用する事 テストメソッドは、非開発者にも伝わるような名前に! パラメータ化を活用する 「確認したいこと」を、より明確に表現できるライブラリ有り。必要に応じて活用する Fluent Assertions メモ AAA テストは Arrange(準備)/Act(実行)/Assert(確認) の3フェーズ(以降AAA)で構成すること 単体テストのテストケースでは、必ず一つの振る舞いだけテストすること 実行フェーズや確認フェーズが複数ある場合、テストを分割すること 実行速度の維持 目的の明確化(この場合、テストで確認したいこと) AAA 以外のフェーズが許されるのは、統合テストぐらい if 文を含む単体テストはアンチパターン if 文が必要なほど、複雑なケースをテストしている、と捉える if 文が不要なくらい、単純なケースをテストするべき テスト・フィクスチャ 「準備フェーズのコードを切り出し、再利用する」というのは良い考え方 「外部結合のmock化」など、全テストケース共通の処理は、コンストラクタがOK 上記以外はファクトリやヘルパークラス・メソッドの活用が吉(※) (※)「全テストケース共通の処理」以外でコンストラクタを利用することは、以下の二つの理由で非推奨 コンストラクタコードとテストコードの結びつきが強くなってしまう テストAのために準備フェーズのコード(≒コンストラクタ)を変更すると、他のテストケースも影響を受けてしまう テストケースの可読性が低下する テストメソッドの命名 テストメソッドの名前には、「確認(検証)したいこと」や「振る舞い」に焦点を当てる 実装に強く依存する(名前に、テスト対象のメソッド名を含むなど)ような厳格な命名規則は、テストコードの保守性低下に繋がり、よろしくない 「確認(検証)したいこと」や「振る舞い」に焦点を当てた名前は、テストの意図を把握しやすい(つまり、読みやすい) テストメソッドの名前に「should」を用いるのはアンチパターン テストメソッド名に希望や要望(つまりshould)を含めるべきではない 希望や要望ではなく、事実(~である、つまり「is」の方が適切

テスト

2023年03月12日(日)

2.0時間

Linux の仕組み 増量改訂版 3章 読了

やったこと Linux の仕組み 増量改訂版 3章を読了 学んだこと sar で取得できる %nice の値は、「ユーザモードでの処理時間の内、nice値を変更した処理時間の割合」という意味 経過時間(real) = 何もしていない時間(sleepなど) + ユーザモードでの実行時間(user) + システムコールによるカーネルの実行時間(sys) 論理CPUをたくさん積んでいるマシンを使用する場合、十分な数のプロセスを実行して初めて、スループットが向上する この時、むやみにプロセスを増やしても、スループットは向上しない 論理CPU数は、workerthread パターンの worker 数を決める際の参考値になりそう あるプロセスのターンアラウンドタイム(処理開始から終了までの時間)が低い場合、「別プロセスが稼働していて、コンテキストスイッチが発生している」という可能性も疑うこと メモ time コマンドで採取できる経過時間 経過時間(real) = 何もしていない時間(sleepなど) + ユーザモードでの実行時間(user) + システムコールによるカーネルの実行時間(sys) コンテキストスイッチ CPU 切り替えのこと。 あるプロセスのターンアラウンドタイム(処理開始から終了までの時間)が低い場合、「別プロセスが稼働していて、コンテキストスイッチが発生している」という可能性も疑うこと。 nice 値 nice 値を変更すると、確かにプロセスの実行順序が変化する。 sar で取得できる %nice の値は、「ユーザモードでの処理時間の内、nice値を変更した処理時間の割合」という意味。 論理CPUを複数使用した並列処理 論理CPUをたくさん積んでいるマシンを使用する場合、十分な数のプロセスを実行して初めて、スループットが向上する。 この時、むやみにプロセスを増やしても、スループットは向上しない。 論理CPU 4つに対して4プロセス が最高性能 これ以上プロセス増やしても、スループットは向上しない 増やしたプロセスはCPU待ち状態になるだけ

Linux

2023年03月12日(日)

2.0時間

インプット大全 読了

やったこと 書籍「インプット大全」読了 学んだこと インプットの質を高めるために、アウトプット前提でインプットすると良い 他人に説明する、感想を言える、記事にまとめて第三者にシェアする ... など 本を読むときは、まず初めにパラパラ読みで全体像を把握する 「全体像の把握 => 詳細を読む」という、ピラミッド構造の流れ 適度な緊張感が、良質なインプットにつながる(ヤーキーズ・ドットソンの法則) アウトプット前提とする 最前列で講義を聞く 質問を前提に聞く(≒質問できるレベルまで、話を理解する) メモは最低限、「どうしても重要な「気付き」をメモする」にとどめる 休憩時間中は、目をつむって、脳を「見る」「読む」から解放する メンター(自分がそうありたいと思うひと)を定める メンターが目標となり、自己成長が加速する 学びを欲張らない まず「3つ」、おわると次の「3つ」と、学習対象を最大3つまでに絞ることで、集中的に学び、学習効率を上げる メモ アウトプットに基本法則 2週間に3回使用した情報は、長期記憶される インプットとアウトプットを繰り返す インプットとアウトプットの黄金比は3:7 アウトプットのフィードバックを得て、改善する 1章 インプットは質より量 例)10冊のショボい本より、1冊の価値ある本 学びたい情報を取捨選択する 無作為にインプットする情報の内、まともに吸収できるのは、わずか3% 不要な情報を捨て、学びたいことに関する情報を集中的にインプットすることが大事 注意深く聞く・読む ここでいうインプットは「読む」「聞く」(個人的には、+体験する) 「なんとなく」行うインプットは、定着率が低い 注意深くインプットする 注意深くインプットするために インプットの目標(方向性とゴール、加えて期限)を設定する インプットとアウトプットを同時に行う(メモを取るなど) アウトプット前提でインプットする 自分の興味ある分野を3つほど特定する(選択的注意にひっかかるようにする) 2章 段階的に学ぶ いきなり専門書は無理なので、入門書 => 授業や講義 => 個人指導 と、徐々にステップアップする アウトプットする 「本10冊インプット、アウトプットなし」よりも、「本3冊インプット、アウトプットあり」 インプットは、アウトプットとペアにして、初めて効果を発揮する 深く読むために 1章 「注意深く聞く・読む」と大体同じ 人に説明できることを前提に読んでみる 本を読んだ「最大の気付き」を書く まず初めにパラパラ読みで全体像を把握する 「全体像の把握 => 詳細を読む」という、ピラミッド構造の流れ 脳にとって、この流れが理解しやすい 読む深さ、速さ共に向上する 3章 講演やセミナーは、最前列で聞く 適度な緊張感が、良質なインプットにつながる(ヤーキーズ・ドットソンの法則) メモは最低限、「どうしても重要な「気付き」をメモする」にとどめる メモを取ることが目的になってはいけない 目的をもって、講演やセミナー聴講に臨む 選択的注意にひっかかるようになる 質問を前提に聞く 質問できるレベルまで、話を理解するようになる 傾聴する 深いレベルで相手をよく理解し、気持ちを汲み取り、共感する 同情と共感は違う 4章 観察する 情報収集力が向上する 変化に敏感になる 流行の把握や、コミュニケーションの質向上につながる 観察力を磨く アウトプットを前提にすると、詳しく観察しようとする 「なぜ?」を突き詰める 2週間に3回以上の「インプット」も効果的 2週間に3回以上の「アウトプット」は非常に効果的 2週間に3回以上の「インプット」もそこそこ効果的 メモを見直すなど 休憩時間は「見ない」 休憩時間中の「見る」「読む」は、休憩に悪影響 目をつむること 5章 情報を見極める 「事実」か「個人の意見」か注意することから 6章 人と会う コミュニケーションを取って、一緒に成長していく クレクレマンになってはダメ 「100人と1回会う」より「10人と10回会う」 メンター(師)を定める メンターは、「自分がそうありたい人」のこと 学習の目標となり、自己成長が加速する 7章 精緻化して覚える 「記銘」「保持」「想起」のプロセスを強化する 精緻化の例 追記(付加情報を追加する) 関連付け(覚えたいことと、自分が知っていることを関連付ける) 言い換え ストーリー化 整理、まとめ(体制化)(図や表、グルーピングなど) 視覚化(写真、画像で表現する) 省察 学びについて自問自答したり、自分の意見・感想を述べる インプット直後にアウトプットする インプット直後の方が「想起」しやすい 学びを欲張らない 学びたいことを「3つ」に絞ることで、絞った対象に集中することが出来、学習効率を高める 脳が一度に記憶・処理できる情報は3つと言われていることに由来 まずは「3つ」、それが完了したら、次に「3つ」...と、「最大3つに絞って集中して取り組む」を繰り返すこと

2023年03月11日(土)

4.0時間

OAuthとOpenID Connect

やったこと https://qiita.com/TakahikoKawasaki/items/498ca08bbfcc341691fe https://www.sassy-blog.com/entry/20171003/1506991888#1-IDToken%E3%82%92%E5%8F%96%E5%BE%97%E3%81%99%E3%82%8B 学んだこと OAuthとOpenID Connect どちらも認可の仕組み。 OAuthを発展させたものが、OpenID Connect。 OpenID Connectは、OAuthの機能に加えて、本人情報(IDトークン)取得の仕組みが盛り込まれた。 OAuth OAuthでは、最終的に、サードパーティアプリケーションに、アクセストークンを発行する。 アクセストークンには、以下の役割がある。 ユーザを一意に特定する 認可範囲を限定する(特定の操作のみを許可するアクセストークンを発行するイメージ) サードパーティアプリケーションは、アクセストークンを使用して、連携したいサービスのAPIを叩く。 OpenID Connect 最終的に、サードパーティアプリケーションに、以下の二つを発行する。 アクセストークン OAuthのアクセストークンと同じ IDトークン ID トークン 「ユーザが認証された」という事実を示す情報。 APIを叩く度に認証する代わりに、APIを叩く際にIDトークンを渡すことで、認証をパスできる(≒認証の手間を省くことができる)。 以下の特徴を持つ。 IDトークンの中には公開鍵情報が含まれており、改ざんを検知できる。 JWT形式

OAuth

2022年08月17日(水)

1.0時間

Docker 基礎

やったこと https://zenn.dev/suzuki_hoge/books/2022-03-docker-practice-8ae36c33424b59/viewer/3-4-volume#%E3%83%9C%E3%83%AA%E3%83%A5%E3%83%BC%E3%83%A0%E3%81%A8%E3%81%AF 学んだこと ブリッジとオーバーレイの違い オーバーレイ 異なるDocker Engine 間で通信する場合に使用 ブリッジ 同一 Docker Engine 内の container 間で通信する場合に使用 ブリッジとホストの違い ホスト ホストマシンと、ネットワーク設定を共有する ブリッジ ホストマシンとは分離された、独自のネットワーク設定を使用する より詳しいブリッジ 以下の二つがある ユーザー定義ブリッジ デフォルトブリッジ デフォルトブリッジ --network オプションを指定しない状態。 デフォルトのnetworkブリッジが割り当てられる。 awsで言う、デフォルトVPCのサブネットというイメージ。 デフォルトブリッジの設定情報は、 daemon.json に記載sれテイル。 ユーザ定義ブリッジ --network オプションにて、自作したnetworkを指定した状態。 awsでいう、自作したVPCのサブネットというイメージ。 関連コマンド ブリッジの詳細情報確認 docker network inspect ブリッジ名 container のネットワーク設定確認 docker container inspect コンテナ名 --network-alias --network-alias にて、コンテナに任意のホスト名を付与できる。 コンテナのIPアドレスを指定する代わりに、設定した network-aliasを使用することができる。 なお、 dokcer-composeの場合、サービス名が --network-aliasとして機能する。 docker-compose docker run コマンドの各種オプションをyaml化していくイメージ。 runに加え、buildも自動化できる。 参考 https://matsuand.github.io/docs.docker.jp.onthefly/network/ https://matsuand.github.io/docs.docker.jp.onthefly/config/containers/container-networking/#dns-services

Docker
Docker Compose

2022年08月16日(火)

2.0時間

React 基礎

やったこと React Testing Library を使用したテストの作成 学んだこと React Testing Library get系 指定の要素を取得する。 名前から「特定の要素が存在することが自明であり、その要素が持つ何か(値など)をテストしたい」時に使用するイメージ。 query系 指定の要素を取得する。 名前から、「特定の要素が存在するか」をテストするときに使用するイメージ。 また、要素が見つからなかった場合の挙動が異なる。 get系 ... エラー query系 ... nullを返却 そのため、「要素が存在しないこと」をテストするときに役立つ。 find系 指定の要素を取得する。 機能的には query と同じだが、queryと異なりpromiseを返却する。 そのため、要素が非同期で取得・表示される場合に活用できる。 参考 https://levelup.gitconnected.com/the-difference-between-get-find-query-react-testing-library-bcd996ba3baa https://dotengineerblog.net/how-to-use-react-testing-library-queries/ Javascript 非同期処理 例外処理 Promise構文の場合、 then().catch で書く。 async/await の場合、try{}catch(){} で書く。 参考 https://qiita.com/soarflat/items/1a9613e023200bbebcb3#%E4%BE%8B%E5%A4%96%E5%87%A6%E7%90%86%E3%82%A8%E3%83%A9%E3%83%BC%E3%83%8F%E3%83%B3%E3%83%89%E3%83%AA%E3%83%B3%E3%82%B0 jest の mock jestのmock関数を使用することで、任意の関数を、ダミーデータを返却する関数へ差し替えることができる。 主に、外部のAPIと通信するような関数( fetch や axios )をmock化する用途で使用される。

React

2022年07月17日(日)

2.0時間

Shell Script 基礎

やったこと 書籍「新しいシェルプログラミングの教科書」 Bash 関数 変数の有効範囲 組み込みコマンド 学んだこと Bash 関数 変数の有効範囲 特に指定がない場合、たとえ関数内で宣言した変数でも、グローバル変数となる。 #!/bin/bash update_hoge() { hoge="hoge" echo $hoge /*hoeg*/ } update_hoge echo $hoge /*hoeg*/ local 修飾子を付与することで、宣言したブロック内でのみ有効な、いわゆるローカル変数となる。 #!/bin/bash update_hoge() { local hoge="hoge" echo $hoge /*hoge*/ } update_hoge echo $hoge /*何も表示されない*/ local 修飾子は、関数内でのみ使用可能。 グローバル領域で使用すると、以下のエラーが発生する。 line 18: local: can only be used in a function ただし、ネストされた関数内までであれば、有効。 #!/bin/bash func2() { echo $hoge /*hoge*/ hoge="fuga" } func1() { local hoge="hoge" func2 echo $hoge /*fuga*/ } func1 echo $hoge /*何も表示されない*/ 呼び出し先(上記の例だと、func2())でも local を付与すると、上書きされない。 #!/bin/bash func2() { echo $hoge /*hoge*/ local hoge="fuga" } func1() { local hoge="hoge" func2 echo $hoge /*hoge*/ } func1 echo $hoge /*何も表示されない*/ FUNCNAME 関数内でのみ使用できる変数。 関数名を取得できる。 #!/bin/bash hoge() { for name in ${FUNCNAME[@]} do echo $name done } hoge hoge main デバッグ等で使用する。 組み込みコマンド : ヌルコマンド 常に終了ステータス0を返すコマンド。 これを活用することで、無限ループを表現できる。 while : do 処理 done printf -v オプション printf の結果を、指定した変数に格納できる。 感想 local 修飾子は、typescriptの const 並みに必須となりそうな予感がする。

ShellScript

2022年06月19日(日)

2.0時間

Shell Script 基礎

やったこと 書籍「新しいシェルプログラミングの教科書」 &> ヒアドキュメント パイプ コマンドのグループ化 学んだこと &> 2>&> と同じ。 標準出力、および標準エラー出力を、リダイレクト先のファイルに書き出す。 & は、「マージする」のような意味。 2>&1 ... 標準エラー出力を、標準出力にマージする 2>1 とすると、「標準エラー出力を、"1"という名前のファイルにリダイレクトする」という意味になる。 ヒアドキュメント ヒアドキュメント中では、パラメータ展開が可能。 #!/bin/bash greet='hello' cat << HELLO $greet hoge fuga test HELLO パラメータを展開したくない場合、終了文字をシングルクォートでくくる。 << の代わりに <<- を使用すると、ヒアドキュメント中の行頭タブが削除される。 <<< はヒアストリング。 以下のように記述することで、ヒアドキュメントを変数化できる。 #!/bin/bash greet='hello' sample=$(cat<< HELLO $greet hoge fuga test HELLO ) echo $sample パイプ 標準出力、標準エラー出力の二つを、まとめてパイプできる。 ls /usr /xxx 2>&1 | less 上記コマンドは、以下の短縮形も存在する。 ls /usr /xxx |& less コマンドのグループ化 { command command ... } 以下二つのプログラムは同義。 #!/bin/bash { date +%Y-%m-%d echo 'test' ls /usr } > result.txt cat result.txt #!/bin/bash date +%Y-%m-%d > result.txt echo 'test' > result.txt ls /usr > result.txt cat result.txt 一行で書くときは、コマンドの後ろにセミコロンを書く。 $ { date +%Y-%m-%d; echo 'test'; ls /usr; } > result.txt サブシェル () と区別して使用すること。

ShellScript

2022年06月18日(土)

2.0時間

Shell Script 基礎

やったこと 書籍「新しいシェルプログラミングの教科書」 process置換 履歴展開 if文 学んだこと process置換 <(任意のコマンド) 例) 何らかのコマンド結果の diff を取る。 diff <(cat w1) <(cat w2) 履歴展開 ! で始まるコマンド群。 !! で、直前に実行したコマンドを参照 !n で、n番目に実行したコマンドを参照 history コマンドや、 ~/.bash_history ファイルから、コマンドの実行順番を取得する !-n で、現在からn個前のコマンドを参照 !any_string で、 any_string から始まる最後のコマンドを参照 if文 例 #!/bin/bash if cd $1; then echo 'YES' else echo 'NO' fi 第一引数にて cd に成功するとtrue、失敗するとfalse。 成功しても、ディレクトリの移動は発生しない。 また、 if で登場する [ は、 test コマンドの短縮形。 そのため、 [ を使用する場合、 test コマンドのオプションをそのまま使用できる。 #!/bin/bash if [ -a $1 ];then echo exists. else echo not exists. fi if文 気になった注意点 記号をシングルクォートで囲む #!/bin/sh str1='abc' str2='123' /* '<' のシングルクォートがない場合、エラーとなる*/ if [ $str1 '<' $str2 ]; then echo 'str1 < str2' else echo 'str1 >= str2' fi これは、条件評価で使用する < > () 辺りの記号が、Linuxコマンドにおける特別な意味(リダイレクトなど)と解釈されるため。 test コマンドに、 '<という文字列'ということを教えるために、シングルクォートで囲む必要がある。 if文の中で何も処理を書かない場合、エラーとなる #!/bin/sh str1='abc' str2='123' /* ifの条件式がtrueの時の処理がないため、エラー */ if [ $str1 '<' $str2 ]; then else echo 'str1 >= str2' fi '何もしない' という処理を書く場合、 : (ヌルコマンド)を記載する。

ShellScript

2022年06月13日(月)

1.0時間

Shell Script 基礎

やったこと 書籍「新しいシェルプログラミングの教科書」 パラメータ展開 文字列展開 置換&展開 コマンド置換 算術式評価 学んだこと パラメータ展開 $(name:-sample) 左辺の変数部分が定義されている場合、左辺の変数の値を展開する。 未定義の場合、右辺の値を展開する。 この時、変数への代入は発生しない ${name:=sample} 左辺の変数部分が空ではない場合、左辺の変数の値を展開する。 空の場合、右辺の値を展開する。 この時、変数への代入が発生する : を省略すると、変数に空文字が代入されているときの振る舞いが変化する。 $ name= $ echo ${name:-sample} sample $ echo ${name-sample} $ $ name= $ echo ${name=sample} $ echo ${name:=sample} sample $ echo $name sample ${name:?hoge} 破片の変数が未定義の場合、右辺を標準エラー出力に表示する。 : がない場合の挙動は、 - や = と同じ。 $ echo ${name:?undefined variable.} -bash: name: undefined variable. $ echo ${name?undefined variable.} 右辺を未設定だと、デフォルトメッセージが表示される。 デフォルトメッセージの方が、「ああ、 :? でエラーが発生しているんだな」と特定しやすいので、下手にエラーメッセージを自作しない方がいいかもしれない。 $ echo ${name:?} -bash: name: parameter null or not set $ echo ${name:+sample} 左辺の変数が定義されている場合、右辺の文字列を展開する。 - の時と逆。 : を省略した場合の挙動も同じ。 文字列展開 $ name=sample /*1番目から末尾まで表示*/ $ echo ${name:1} ample /*末尾から2文字を表示*/ $ echo ${name: -2} le /*1番目を起点に、3文字表示*/ $ echo ${name:1:3} amp /*先頭一番目から、末尾から1文字まで を表示*/ $ echo ${name:1:-1} ampl 配列の展開でも、上記と同じ記法を用いる。 $ ary=(aaa bbb ccc ddd) $ echo ${ary[@]:1} bbb ccc ddd $ echo ${ary[@]: -1} ddd $ echo ${ary[@]:1:2} bbb ccc /*これだけエラー*/ $ echo ${ary[@]:1:-1} -bash: -1: substring expression < 0 $ echo $name sample $ echo ${#name} /*文字列の長さを取得*/ 6 ${name#hoge} hoge と前方一致した部分を取り除きつつ、変数展開する。 $ name=sample $ echo ${name#sam} ple 先頭が一致しない場合、何も取り除かれない。 $ echo ${name#smp} sample ## で最長一致( # だと最短一致 ) $ file=sample.tar.gz $ echo ${file#*.} tar.gz $ echo ${file##*.} gz ${name%hoge} hoge と後方一致した部分を取り除きつつ、変数展開する。 $ name=sample $ echo ${name%ple} sam 末尾が一致しない場合、何も取り除かれない。 $ echo ${name%mpl} sample ## で最長一致( # だと最短一致 ) $ file=sample.tar.gz $ echo ${file%.*} sample.tar $ echo ${file%%.*} sample 例1) ファイル名だけ取り出す $ echo ${file} sample.tar.gz $ echo ${file%%.*} sample 例2) 拡張子だけ取り出す $ echo ${file} sample.tar.gz $ echo ${file#*.} tar.gz 例3) ファイルの絶対パスから、ファイル名だけ取り出す $ log_path=/var/log/hoge.log $ echo ${log_path##*/} hoge.log 置換&展開 $ echo ${file} sample.tar.gz /*最初にマッチした部分を置換する*/ $ echo ${file/./_} sample_tar.gz /*マッチする部分は全部置換する*/ $ echo ${file//./_} sample_tar_gz コマンド置換 $ touch $(date +%Y-%m-%d)_hogehoge.log $ ls 2022-06-12_hogehoge.log 算術式評価 $ x=8 $ y=20 $ ((z=x+y)) /*z => 28*/ $ let z=x+y /*z => 28*/ または、変数を整数型で宣言する。 $ declare -i sum $ sum=x+y /*sum => 28*/

ShellScript

2022年06月12日(日)

2.0時間

typescript 基礎

やったこと 【世界で7万人が受講】Understanding TypeScript 日本語版 学んだこと Union型 「AまたはBの型」といった表現が可能になる。 const combine = (input1:number | string, input2:number | string):number | string => {...} Literal 型 「特定の値を持ったオブジェクトのみ有効」といった表現が可能 const combine = ( input1: number | string, input2: number | string, resultConversion: 'as-number' | 'as-string' ): number | string => {...} 上記の ResultConversion は、String型の内、 as-number と as-string という値のみ引き受ける。 これで、任意のstring型がやってくる可能性を排除できる。 alias型 type キーワードを使用した、任意の型を定義できる機能。 型定義に新たな名前を付与でき、再利用性を高める。 type addNumber = (n1: number, n2: number) => number; /*関数の型*/ type Combinable = number | string; /*Union型*/ type ResultConversion = 'as-number' | 'as-string'; /*Literal型*/ type TodoType = { /* Object型 */ userId:number; id: number; title: string; completed: boolean; } typeで定義した型は、 export することで、ファイル分割された他のソースコードから参照できる。 Pick と Omit の復習 既存のオブジェクトから任意のフィールドを抜き出し、新たなオブジェクトを定義する記法。 export type TodoType = { userId: number; id: number; title: string; completed: boolean } ... const Todo = (props: Omit<TodoType, "id">) => {...} const Todo = (props: Pick<TodoType, "userId","title","completed">) => {...} any型よりもunknown型 unknown型の変数を他の型(例えばstring)の変数へ代入するには、型チェックしなければならない(コンパイルエラーが発生する)。 any型で同様のことを実施すると、コンパイルエラーが発生しない。 コンパイルエラーを発生させ、プログラマに注意を促す意味で、unkown型の方が推奨される。

TypeScript

2022年05月21日(土)

2.0時間

サーバ/インフラを支える技術

やったこと サーバ/インフラを支える技術 4章 読了 5章 途中まで 学んだこと sar ( System Activity Reporter ) CPU負荷、およびI/O待ち率を表示するコマンド。 ■%userの値が高い ユーザが実行したプログラムが、CPUを大量に使用していることを示す。 ■%system の値が高い 以下を示す。 大量のプロセス/スレッドを動作させている システムコールの呼び出し頻度が高い ■%iowait の値が高い I/O処理完了の待ち時間が長いことを示す。 マルチコア環境だと、特定のCPUに負荷が偏っている可能性がある。 sar -P ALL オプションにて、各CPUの負荷を見比べることも大事。 ロードアベレージ システム全体の負荷を表す指標。 CPU使用率やI/O待ち率は、CPU個別の負荷を表す指標。 ロードアベレージにて、システム負荷の有無を把握する。 負荷があれば、CPU使用率やI/O待ち率から、負荷の詳細を追っていく。 カーネルにとって、プロセスとスレッドは大差ない。 全く同じロジックでスケジューリングされる。 スレッドは、LWP ( Light Weight Process )とも呼ばれる。( ps -L コマンドにて、 LWPという項目が表示される) ps auxw 要点 ■VSZとRSS VSZは仮想メモリサイズ、RSS は物理メモリサイズを表す。 RSSが大量に消費されている場合、スワップが発生している可能性がある。 ■TIME プロセスがCPUを使用した時間。 CPU負荷が高い場合、TIMEの値を確認することで、どのプロセスがCPUを占有しているのか判断できる。 無限に足し算を行うようなループだと、TIMEの値がどんどん増える ユーザの入力待ち状態だと、TIMEの値は変化しない Linuxのページキャッシュ Linux は、空きメモリを、可能な限りページキャッシュに回そうとする。 頻繁にReadするデータを事前に読み込むことで、意図的にページキャッシュへ回すことができる。 RDBだと、起動直後はページキャッシュが空の状態。 この状態では、ディスクまでI/Oが発生するため、起動直後はパフォーマンスが低い。 まとめ ■ロードアベレージから、システム全体の負荷の有無を読み取る top コマンドにて確認。 ■CPUに負荷をかけているのはユーザとシステムのどちらか確認する sar コマンドにて確認。 %user の値は、ユーザがCPUに負荷をかけている割合を示す %system の値は、システムがCPUに負荷をかけている割合を示す (マルチコア環境では sar -P ALL にて、CPU別の負荷を確認できる) ■I/O待ち時間の有無を確認する sar コマンドにて確認。 %iowait の値は、IOによる待ち時間を示す ■システムに負荷をかけているプロセスを特定する ps auxw コマンドにて確認。 RSSの値が大きい場合、スワップが発生している可能性がある TIMEの値が大きい場合、対称プロセスがCPUを占有している可能性がある ■スワップ発生状況を見る sar -W コマンドにて確認。 ■I/Oのデータ量を確認する vmstat コマンドにて確認。 biがディスクからの読み出し、boがディスクへの書き込みを示す 考えられそうな対策 ■CPU負荷が高い スケールアウトする アルゴリズムを見直す ■ディスクIOが高い メモリを増設する(≒ページキャッシュの増設) キャッシュソリューションを導入する MemcachedやRedis Webサーバのチューニング 方針 より多くのクライアントを、一度に捌くことができること。 一クライアントに割り当てるコンピューティングリソースを抑えること。 マルチプロセスかマルチスレッドか Webサーバのメモリ上限や、アプリケーションにおけるコンテキストスイッチの回数を参考に、マルチプロセスかマルチスレッドかを選択する。 クライアント数の上限値 Apacheであれば、以下の二つのパラメータが該当。 ServerLimit プロセス数の上限 MaxClient 同時接続可能なクライアント数の上限 マルチプロセス環境であれば、両者はほぼ同義。 マルチスレッド環境であれば、以下の通り。 ServerLimit * ThreadLimit = MaxClient コンテキストスイッチ プロセスを切り替える処理のこと。 コンテキストスイッチが発生しないマルチスレッドは、高速な処理が可能。 マルチスレッドが効果を発揮する場面 大量のコンテキストスイッチが発生するような処理 メモリ消費を抑えたい場合(メモリ容量が小さいなどの理由) Copy on Write メモリの更新処理が走るときに初めて、子プロセスが親プロセスから値をコピーするという挙動。 Auroraのクローンと、考え方は同じ。 Apache MaxRequestPerChild ディレクティブ 子プロセスが捌ける、最大リクエスト数を設定する項目。 最大リクエスト分を捌ききると、子プロセスを終了させ、新規に子プロセスを立ち上げる。 新規に子プロセスを立ち上げる(≒親プロセスからforkする)ことで、メモリ空間を完全に共有した状態に戻すことができる。 つまり、メモリを節約できる。 サービスの稼働監視 稼働監視は、以下の三つに分類される。 ホストやサービスの死活監視 そもそもサービスが提供できているのかを監視する ホストやサービスの負荷監視 死活監視では検出できない、「一応使えるけど何か遅い」を検出する 一定期間(1か月や一年)の稼働率計測 中長期的に監視を続けることで、「不安定なサーバの検出」や「不安定なシステム構成のあぶり出し」、つまり継続的な改善が期待できる サーバリソースのモニタリング サーバリソースの変動を観察する活動。 変動を継続的に記録し、視覚化によって傾向や変動を把握しやすることで、トラブル発生時の原因究明に役立てる。 観察する指標の代表は、以下の通り。 CPU使用率 メモリ使用率 ロードアベレージ ネットワークトラフィック サーバ管理の効率化 サーバを複数台運用する場合、一つ一つ人手で設定すると、設定漏れが発生する。 複数のサーバの設定管理を、まとめて、効率的に実施したい。 サーバ管理ツールを導入することで、これらを達成できる。 特に、以下における設定の反映を効率化できる。 新規サーバの投入時 既存サーバの設定変更時

Infrastructure

2022年05月06日(金)

4.0時間

サーバ/インフラを支える技術

やったこと サーバ/インフラを支える技術 3章 4章途中まで 学んだこと MySQL スレーブの活用 スレーブを活用して、READ処理を負荷分散する。 マスタ : Update Insert Delete スレーブ : Select 内部LBを構築して、Selectクエリを複数のスレーブで負荷分散する。 ストレージサーバ アプリケーションで使用するファイルを保存したストレージ。 以下の手段がある。 nfs でマウントする ストレージをWebサーバとして構築し、httpでアクセスする 現在だと、自前でストレージサーバを構築するより、S3などのクラウドストレージが有力だと思う。 DNSサーバの冗長化 DNSサーバ障害の対策は、大きく二つ。 resolve.conf に、二つ以上のDNSサーバを指定する DNS問い合わせでタイムアウトが発生すると、二つ目以降のDNSサーバへ問い合わせる クライアント側はこれでOK サーバ側は、「タイムアウト」による性能低下が問題にある DNSサーバを冗長構成化する DNSサーバの障害は、滅多に発生しない。 しかし、いざ発生すると、「DNSサーバが原因だった」と特定するのに、非常に時間と労力がかかる。 万が一に備え、DNSサーバの冗長化(冗長化に加えて、フェイルオーバー時に通知する)など、対策を取っていきたい。 DRBD (Distributed Replicated Block Device) ストレージサーバの冗長化に使用されるsoftware。 ネットワーク越しのRAID1。 ネットワークの冗長化 Boundingドライバ 複数の物理NICを、一つの論理的なNICにまとめることができるソフトウェア。 サーバとスイッチ間の冗長化に加えて、スイッチの冗長化も実現できる。 物理NICの故障検出にて、以下の二つの方法が用意されている。 MII (Media Independent Interface) 監視 物理NICのリンクダウンを確認する リンクダウンを伴わない障害は検出できない ARP監視 ARPリプライが返ってくることを確認する ARPを送信する相手は選ぶこと 相手がARPリプライを返さないと、誤検知につながる 大体こっちを使用する VLANの導入 サーバファームにおける「柔軟性の高い」とは 以下の条件を満たす状態を指す。 新規サーバを容易に追加できる サーバが故障した時、すぐに代替機へ移行できる あるサーバを別の役割のサーバとして切り替える VLANを使用することで、上記を達成することができる。 VLAN導入のメリット 一台のスイッチで複数のセグメントを管理できる 一台のスイッチを、有効活用できる 設定により、ポートを流れるデータを制御できる サーバ追加/置き換え、故障時の代替機による復旧が、設定変更で完結する タグVLANとポートVLANは併用可能。 うまく併用して、物理配線、および論理設定をシンプルに保ちたい。 4章 性能向上・チューニング 性能とは・負荷とは 「負荷」と呼ばれるものを具体的に知ること。 「負荷」を知るということは、OSの状態を知るということ。 OSの動きを理解し、各種パラメータを計測し、「負荷」を正しく理解する マルチタスクの動作原理を学び、プロセスの状態と負荷の関係を理解する I/OがOSによってどのように処理されるかを学び、「ディスクI/Oの分散と軽減作業(キャッシュとか)」を理解する 推測するな、計測せよ 性能を引き出すためには、サーバリソースの利用状況を正確に把握する必要がある。 負荷分散の正解でも、負荷を「推測するな、計測せよ」の精神で、負荷を計測し、適切なチューニングを行う。 Linuxカーネル(OS)から、負荷に関わる多くの情報を得ることができる。 まずはこちらから。 ボトルネックを見極める 1) ロードアベレージを見る システム全体の負荷状況を示す指標 ここが高ければ、次へ進む 2)CPU、I/Oのいずれがボトルネックかを探る sar や vmstat にて、CPU使用率やI/O待ち率の推移を確認する。 3-1)CPU負荷が高い場合 原因は、次のどちらか 他のリソースはボトルネックになっていない、理想的な状態 プログラムの暴走によって、CPUへ必要以上の負荷がかかっている 3-2)I/O負荷が高い場合 原因の大部分は、次のどちらか。 プログラムによる大量の入出力 スワップによるディスクアクセスの発生 負荷とは 大きく次の二つ。 CPU負荷 I/O負荷 APサーバは、プログラムを実行するという、CPU負荷に依存する仕事がメイン。 DBサーバは、ディスクに保存しているデータをRead/Writeするという、ディスクのI/O速度に依存する仕事がメイン。 マルチタスクによる負荷分散 タスクが増えると、CPUが空くまで待たされるタスクが増えていく。 この待ち状態は、プログラムの実行遅延という形で現れる。 これらは、 top の load average の数字から読み取れる。 load average は、「処理を実行したくても、実行できなくて待たされているプロセスが、どの程度存在するか」を表す。 具体的には、以下の二つ。 CPU実行権限が与えられるのを待っているプロセス ディスクIOが完了するのを待っているプロセス load average の値が高い状況は、タスクの実行に待ち時間が大きいことを表している。 「タスクが待たされるのは、どのような場合か」を知る必要がある。 これを知るには、プロセス(OS)の状態遷移を理解する必要上がる。 プロセス(OS) 「プログラムの命令」と「実行時に必要な情報」を一つにまとめたオブジェクト。

Infrastructure

2022年05月05日(木)

3.0時間

サーバ/インフラを支える技術

やったこと サーバ/インフラを支える技術 ~85p 学んだこと ##冗長化のステップ 障害を想定する 障害に備えて予備の機材を準備する 障害発生時、予備の機材に切り替える運用体制を整備する 予備系への切り替え ■前提 主系と予備系は、常に同じ設定であること。 ■ホットスタンバイ データを蓄積する、設定変更(特にソフトウェアアップデート)を頻繁に行う機器は、ホットスタンバイが良い。 ■コールドスタンバイ データを蓄積せず、設定変更がほぼない機器は、コールドスタンバイも選択肢に入る。 ルーターやスイッチなど VIP 仮想的なIPアドレス。 引継ぎ可能であり、実IPアドレスに左右されないため、I/Fのように機能する。 ヘルスチェックの考え方 「何を確認したいか」を明確化することが重要。 Webサーバのヘルスチェック 確認したいこと : サーバの応答が正常であること 確認方法 : サービス監視(L7) ルーターのヘルスチェック 確認したいこと : ルーターがパケットを正常に転送すること 確認方法 : 公開Webサーバあての ping(ルーター宛てだと、パケットを転送しない) DNS ラウンドロビンについて 負荷分散の仕組みであって、冗長化の仕組みではない。 負荷分散の仕組みと冗長化の仕組みは、分けて考えること。 いまやLBは、専用アプライアンスではなく、Linux上で動作するOSSとして利用できる。 リバースプロキシ CDN的な役割 リバースプロキシに、静的コンテンツを配布するCDNのような役割を持たせる。 静的コンテンツの配布はリバースプロキシ、動的コンテンツの配布はAPサーバ、と役割を分けることで、APサーバのリソース効率を向上させることができる。 Apacheの場合、 RewriteRule にて設定する(正規表現使用可能)。 Keep Alive 対応リソースの節約 前提として、プロセス/スレッドのメモリ消費量は次の通りと仮定する。 リバースプロキシ < APサーバ クライアントとリバースプロキシ間は Keep AliveをONにする。 リバースプロキシとAPサーバ間は Keep Alive を OFFにする。 これにより、Keep Alive によるリソース消費を顕現できる。 総じて、リバースプロキシの導入により、システムの柔軟性が向上する。 Apacheの設定 ServerLimit : 生成できるプロセスの最大値 ThreadLimit : 生成できるスレッドの最大値 MaxClient : ServerLimit * ThreadLimit ThreadPerChild : 1子プロセスあたりのスレッド数。だいたいThreadLimit。 ServerLimitとThreadLimitは、Apacheが確保するメモリ量に影響を与える。 MaxClientとThreadPerChildは、Apacheが確保したメモリ量内で、生成可能な最大値 プロセス/スレッド数設定のヒント プロセス/スレッド数が上限に達した時、スワップが発生しない程度の値が良い。 リバースプロキシ設定例 特定ホストからのリクエストをブロック ロボットからのリクエストは、キャッシュサーバへ 静的コンテンツは /hoge/foo/bar/へ 動的コンテンツは http:APサーバ へ など キャッシュサーバ Squid プロキシとしても、キャッシュサーバとしても利用可能なOSS。 静的なコンテンツのキャッシュを得意とする一方、「動的コンテンツをT秒キャッシュする」といった柔軟な設定も可能。 ユーザごとに内容が変化するページでは、キャッシュは困難(機微な情報の流出につながる) memcached キャッシュソリューション。 プログラムからアクセスする。 memcachedを別サーバに立てて、ネットワーク越しにアクセスする、といった使い方が可能。 MySQL バイナリログとリレーログ マスタにはバイナリログ、スレーブにはリレーログ(任意でバイナリログも出力可能)が記録される。 バイナリログは、更新系のクエリを、バイナリ形式で記録する。 リレーログは、マスタから送られてきた更新系クエリを一時的に記録する。 (更新系クエリをスレーブへ反映し終えた後で、該当クエリを削除すると思われる) ポジション情報 スレーブが保持する、以下の情報の総称 マスタのホスト名 ログファイル名 ログファイル中の処理したポイント show slave status 文で確認できる。 以下がそろっていれば、最新のマスタに追従するスレーブを作成できる。 ある時点におけるマスタのフルダンプ ポジション情報 マスタのバイナリログ

Infrastructure

2022年05月04日(水)

3.0時間

183件中の 76-100件 を表示