kmuto’s blog

料理と旅行といろんなIT技術

『Software Design』2023年4月号を読んだ

tech

gihyo.jp

WEB+DBのmasayoshiさんSRE記事が完結したけど、SDでキャディ社のSRE記事が始まった。

  • 「平林万能IT技術研究所」
    • グリコ森永事件の中の1つの話題であった、21面相/玉三郎の無線交信から、電波伝達の話。面白い。
  • 「結城浩の再発見の発想法」
    • 今回はIDの話。唯一性・有効範囲・変更可能性。次回で終了かー。
  • 「一度は学んでおきたいCPUのしくみ」
    • uchanさんらによる記事。ISA、論理演算、レジスタ、アセンブラ、MA、パイプライン、キャッシュ、並列処理、SIMD。わかる内容多めだけど、クラウド時代でこれからこのあたりに興味持つ人はさらに減っていくのかな…。
  • 「新人に読ませたい技術書ベストセレクション」
    • 制作お手伝いした本はそんなには登場していなかったけど、まとまった知識としてやっぱり技術書買って読んでほしいね。
  • 「Denoで始めるサーバサイドTypeScript開発」
    • CSVからMarkdown表に変換するのを例に、Denoのモジュールの作り方。モジュールの作成・公開は簡単そうだった。ただしdeno.land/xはGitHub連携・モジュール名ユニーク・一度登録したモジュールは削除できないという前提制約がある。先願で汚染・サブマリンしておくこともできそうだな…と思ったけど、そのあたりはあまりどうにもならなそうだろうか。
  • 「Google Cloudを軸に実践するSREプラクティス」
    • キャディ社さんのSRE話。技術選定として、IaC・自動化・オブザーバビリティ・セキュリティの4点を重視。GKE、Cloud Run、BigQuery、Cloud SQL、Vertex AI、Anthos Service Mesh、Cloud Logging、CLoud Traceを利用。GCなのは単純にGoogle Workspace理由なのが始まりだったらしいけど、コンテナ化でGKEが選べたのはよかった、と。
    • IaCはTerraformとArgo CD。自動化はGHA・Renovate。
    • オブザーバビリティはAnthos Service Mesh・Datadog・Cloud Logging・Cloud Trace。Datadogはサービスログやメトリクスを収集し、SLI/SLO・稼働状況可視化・サービス異常検知・外形監視・証明書期限など。マルチクラウド、ログとメトリクスの収集、ダッシュボードの可視性や調査時検索性の良さが選定理由。Cloud Loggingとの使い分けとしては、Cloud LoggingはDatadogに収集していないログの参照・過去ログ検索(Datadogに全部入れるとコストの問題、およびログ保存期間の問題)。Cloud TraceについてもDatadog APMより低コスト。Google Cloud Managed Service for Prometheusで代替できるかもという可能性。
    • セキュリティはCloudflare。DNS・Access・WAF・Workersなど。
  • 「three.jsでお手軽3Dプログラミング」
    • そういえばモデリング試せてない…。座標系。DoGAは左手だったっけかな？ 直方体を並べて雪の結晶を構成するサンプル。
  • 「『らしさ』の本質に迫るGo言語」
    • 関数、メソッド、パッケージ名の命名ルール。
    • メソッドはレシーバーを持った関数。レシーバー名は、多用されるなら不必要に長くheaderというよりもhでいい。やるなら統一、さもないと込めていない意図を勘繰られてしまう。OOPじゃないのでme・this・selfは使わない。関数引数名はある程度は説明的なものにする。名前付き戻り値は通常は避けるが、同じ型の複数戻り値があるときには付けて明示化する。
    • パッケージ名は短く簡潔、かつ役割を連想できる名前に。アンダースコア・大文字使わない。単数形。パッケージ名+識別子名のセットで過不足ないものを考える。uuid.NewUUIDではなくuuid.Newみたいな。util/common/sharedみたいなありきたりな名前を避ける。
  • 「リソースから考えるBCPの手引き」
    • 情報リソースの話。事業情報・個人情報などが含まれ、保管が必要な資源。電子データ・紙媒体・電子媒体など。データを復旧すればよしではなく、どの時点のデータが事業継続に必要か。事前対応はバックアップ・保管。初動対応は状況確認。復旧対応は電子データは必要に応じてリストア。サイバー攻撃の場合は被害前の時点へ。紙は原本は再発行依頼。
  • 「AWS活用ジャーニー」
    • ECS。今知りたい情報だ。
    • オーケストレータ、コントロールプレーンをAWSがマネージド。
    • 実行環境、データプレーン。Fargate、EC2、ECS Anywhere(EXTERNAL)。EC2のAMIはAmazon ECS-optimized AMIが使われる。ECS AnywhereはオンプレやVMでコンテナを実行するもので、SSM、ECSコンテナエージェント、Dockerをインストールする必要あり。
    • ECR、コンテナレジストリ。パブリック/プライベートのリポジトリ作成可能。VPCエンドポイントでプライベートに取得できる。
    • EKS、マネージドKubernetes。
    • Fargate。サーバレスコンピューティングエンジン。CPU/メモリを指定。料金も比例。
    • タスク定義。タスクまたはサービスのテンプレート。docker-compose.ymlのようなもの。起動タイプにより指定しなければいけないパラメータは異なる。タスクで使うIAMロール、タスクが使うCPU/メモリ量(Fargateの場合)、起動タイプ、コンテナのDockerイメージ、コンテナが開くポート、ログ設定など。
    • タスク。タスク定義に基づいて起動されるコンテナ群。コンテナは同一ホスト上で実行される。タスク定義のインスタンス、と呼ばれることもある。スタンドアローンタスク(バッチジョブなど)、またはサービスの一部(Webサーバなど)として実行できる。Amazon EventBridgeルールを使ってタスクスケジューリングもできる。
    • サービス。ECSクラスター内で指定した数のタスクを同時に実行して維持する。Application Auto Scalingと統合されていて、タスクの必要数をオートスケールする(CloudWatchメトリクス、またはスケジュール)。サービス間負荷分散ELBとしてはALBかNLB、ALBが推奨。
    • クラスター。タスクまたはサービスの論理グループ、コンテナインスタンスの集合。タスク/サービスは起動タイプ(インスタンス)で実行されることになる。EC2の場合はキャパシティプロバイダでAuto Scalingグループを指定し、コンテナインスタンスをスケールする。Fargateはマネージドなので考えなくていい。
    • ECSクラスター管理のVPC作成、IAMロール・Dockerイメージ作成、ECSクラスター作成、タスク定義登録、タスクまたはサービス作成。
  • 「魅惑の自作シェルの世界」
  • 「Ansible 現場を支えるPlaybook」
    • Ansible Automation PlatformでServiceNowチケット管理と組み合わせる話。そういえばGitHubとBacklogあたりも何か連携できそうなのかな。
  • 「エンジニアも知っておきたい法律知識」
    • 納期先行&未契約のような、契約の成立が問題となる類型。契約成否、不誠実な交渉破棄で争う。契約書がないのが問題。キックオフや開発着手意向などを推認とする。
    • 手戻りで開発頓挫するような、開発の中断が問題となる類型。ベンダーのPM業務とユーザーの協力義務で争う。ユーザー側の中途解約権行使の場合はベンダーの損害賠償で争う。ベンダーは予定完遂していてユーザーの仕様変更によることを積極的に議事録に残す。ユーザーは遅延頓挫原因がベンダーの検証不足などにあることを議事録に残す。工程管理表を用意する。
    • 検収不合格(完了前)・契約不適合(完了後の保証期間)など、成果物の仕様が問題となる類型。RFP・仕様書・要件定義書・仕様変更合意書の記述。
    • いずれにしてもメール・チャットなどで議事内容や意思決定の過程を形に残す。

次回はPython×数学、WebAssembly、と。新連載のメールセキュリティ対策の現場も気になる、おうちサーバで使えるのが出てくるといいんだけど。