ssmonline #43 での発表資料です。 (運用設計ラボ合同会社 波田野裕一)

はじめに こんにちは、皆さん。今日は、シェルスクリプトを使った高度な自動化のベストプラクティスとパターンについて解説します。これらは、ちょっとした知識で実行でき、作業を大幅に効率化できるTipsです。シェルスクリプトは、特にUNIX系システムでの自動化タスクに欠かせないツールです。適切に使用すれば、複雑なタスクを効率的に、そして信頼性高く実行できます。 トイルとは、反復的でマニュアルな作業のことを指します。これには、例えば、手動でのシステムのスケーリングや、エラーのトラブルシューティング、ルーティンなメンテナンス作業などが含まれます。トイルを特定し、それを自動化することで、エンジニアはより創造的なタスクやプロジェクトに焦点を合わせることができます。 トイルを判別する方法としては、以下のような基準が挙げられます： 手作業であること 完全な手作業だけでなく、「あるタスクを自動化するためのスクリ

今回は、SSH接続を劇的に高速化する方法をご紹介します。たった3行の設定を追加するだけで、接続時間を10分の1に短縮できます。しかも、2回目以降の接続では認証も自動的に行われるので、パスワードやパスフレーズの入力も不要になります。 要点 .ssh/configファイルのHost *セクションに以下の3行を追加するだけです。 詳しい説明 1. ControlMaster auto この設定で、1つのSSH接続で複数のセッションを共有できるようになります。新しくSSH接続を確立するたびに認証情報を入力し直す手間が省けて、接続がぐっと速くなります。具体的には： 初回の接続時のみ認証が必要 2回目以降は既存の接続を再利用するため、認証プロセスをスキップ パスワードやパスフレーズの入力が不要になり、接続がほぼ瞬時に完了 2. ControlPath ~/.ssh/mux-%r@%h:%p Contr

Cacti の Percona のテンプレートを使う場合、Cacti から監視対象のサーバに SSH で接続してメトリクスを取ってくることになるのですが・・・普通にやると都度サーバにSSH接続する事になりますし、対象サーバの /var/log/secure にログが無駄に記録されて辛いです。 そこで ControlMaster を使います。 ControlMaster とは 適当なディレクトリに ssh_config を下記のように作成します。 ControlMaster auto ControlPath ~/.ssh/mux-%r@%h:%p ControlPersist 10m ssh -F ssh_config ... のようにこのファイルを指定して対象サーバに接続します。すると・・・ 最初に接続しようとしたときにバックグラウンドでマスター接続を張るプロセスが起動する このマスター接

はじめに こんにちは！DPE（Developer Productivity Engineering）チームの高畑です。 最近カーオーディオにハマっていて、スピーカーを変えたり DSP アンプを導入したりとオーディオの沼に腰あたりまで浸かってしまいました。 スピーカーケーブルをちょっと良いやつに変えたりしてみたんですが、正直違いが分かっていないので頭まで浸かるのはまだ先のようです。 現在、ビザスクでは遅ればせながら MySQL 5.7 から MySQL 8.x へアップグレードするためのプロジェクトが進行しており、既存のデータを移行するため諸々の検証を行なっていました。 検証を進めるにあたり、データの移行に DMS (Database Migration Service) を利用する方針となったので、経緯や方法をご紹介したいと思います。 移行方法の検討 当初、既存の MySQL 5.7 デー

はじめに サーバーレス大好きなエンジニアです！ AWS SUMMIT 2024に行ってきて、たくさんのことを学んできました！ 特に「サーバーレス開発のベストプラクティス」の内容が面白かったのでシェアしたいと思います。 サーバーレスとは サーバーやインフラの管理を気にすることなくアプリケーションを実行することができる最高の技術です。細かい設定を気にすることなく、すぐに価値を提供できることが魅力です。 Lambdaのベストプラクティス ここからAWS SUMMIT 2024の内容に触れていきます。 TransportではなくTransform まず、ハッとさせられたのは以下のことです。 Transport （転送）ではなくTransform（変換）に使⽤する。 今までLambdaをどれだけ転送機能として使ってきたかを考えさせられました。 何でもかんでもLambdaに任せるのではなく、特定の変換

TiDB User Day 2024の登壇資料です。

個人的に「Webサービスの公開前チェックリスト」を作っていたのですが、けっこう育ってきたので公開します。このリストは、過去に自分がミスしたときや、情報収集する中で「明日は我が身…」と思ったときなどに個人的にメモしてきたものをまとめた内容になります。 セキュリティ 認証に関わるCookieの属性 HttpOnly属性が設定されていること XSSの緩和策 SameSite属性がLaxもしくはStrictになっていること 主にCSRF対策のため。Laxの場合、GETリクエストで更新処理を行っているエンドポイントがないか合わせて確認 Secure属性が設定されていること HTTPS通信でのみCookieが送られるように Domain属性が適切に設定されていること サブドメインにもCookieが送られる設定の場合、他のサブドメインのサイトに脆弱性があるとそこからインシデントに繋がるリスクを理解してお

import React, { useState, useCallback, useMemo } from 'react'; const AmbientSynth = () => { const [audioContext, setAudioContext] = useState(null); const [activeOscillators, setActiveOscillators] = useState({}); const initializeAudioContext = useCallback(() => { if (!audioContext) { const context = new (window.AudioContext || window.webkitAudioContext)(); setAudioContext(context); } }, [audioConte

↓↓↓↓訂正あります。↓↓↓↓ 2018/07/02に株式会社エフコード社内で行われた勉強会のスライドです。 訂正版(随時更新中): https://docs.google.com/presentation/d/15HOMfAbtdWwO48njcB8IdkN3kVAMu3wsmZo0O3S-f_4/edit?usp=sharing 専門家による資料・専門家向けの資料ではありません。自分自身で学習し、論文・文献等を読解してまとめた内容となります。間違い等あるかもしれませんが、あれば是非コメント頂ければと思います。 【訂正事項】 スライド16: 誤：たった一つのプロセスが故障しただけでも有限時間で合意できない 正：たった一つのプロセスが故障しうるだけでも有限時間で合意できない スライド20: 誤: 重要: あるschedule σ1, σ2 がdisjoint (nodeが被ってない) なら

2024年6月22日に開催された「第14回　関西DB勉強会 」での、 『こんなに違うよ MySQLとPostgreSQL ～MySQLとPostgreSQLのニッチな違いを語る～』 の発表資料です。 https://kansaidbstudy.connpass.com/event/316348/

本記事は「珠玉のアドベントカレンダー記事をリバイバル公開します」企画のために、以前Qiitaに投稿した記事を一部ブラッシュアップしたものになります。 はじめにみなさん、docker composeを利用しているでしょうか？ 複数のdockerコンテナをまとめて立ち上げたり、環境変数を定義できたり便利ですよね。 この記事ではある程度docker composeを利用している方向けに私が便利、便利そうと感じたdocker composeの機能を挙げてみました。 docker compose cli v2を利用docker-composeではなく docker composeコマンドも利用可能になっています。 Docker Desktopでは v3.4.0から利用可能で、基本的にはコマンドの互換性あります。 ファイル監視による自動更新docker compose 2.20.0からCompose

Twitterとか見て「そうだったのかー」とか言うんじゃなくて、ちゃんと調べてみましょうよ。/usr は元々ユーザーのホームディレクトリをおいていた場所ですよ。/bin などを置いていたシステムディスクの容量が足りなくなったので別ディスクだった /usr 以下を使うようになっただけです。Unix System Resources とかそんな長い名前、後付けに決まってるでしょ？ 翻訳は面倒なので、DeepL（の少し手直し）です。 初期の Unix のドキュメントから URLと1972年という年から、おそらく Version 1 Unix (1971) のドキュメントだと思います。ここ 経由で見つけました。 12ページにこのようなものがあります。詳細はよくわかりませんがディレクトリ構造でしょう。 idata: / root 41. 140016 .byte 7,1 9f-.-2 41. <..

API経由でメール送信をするためのサービスといえば、SendGrid, Amazon SES, Postmarkのような名前が出てくるかと思います。 そんな中、弊社(トラストハブ)でも利用しているResendというサービスがとても使いやすいので紹介します。また、記事後半でResendを日本で使うにあたり重要なアップデートがあったので、どんな点が変わったかを紹介します。 そもそもResendとはどんなサービスか Resendは後発サービスなだけあり、開発体験の良さに主眼が置かれて開発されています。テストでメールが送信できていることを確認する機能や、ログを確認する機能など、細かいところが使い勝手が良いなと感じています。 SDK・設定がシンプル 公式でたくさんの言語のSDKが用意されています。また、フレームワークごとに組み込むためのドキュメントも充実しています。 Knowledge Baseを見

いただきましたー！わーい。脳に収めるぞー！ @haradakiro @ryuzee pic.twitter.com/3Qd6EvPioU— SHIIBA Mitsuyuki (@bufferings) June 13, 2024 明日（2024年6月18日）発売！ www.oreilly.co.jp どう書くのがいいんだろうなぁ？ 複雑なコードと向き合うときは「あー、これはメモを取りながら読まないと迷子になるやつだ」ってなる。最初はわりとキレイに作られていたとしても、機能追加を重ねていくとだんだん読めなくなっていく。 だから「時間が経っても読みやすいコードってどう書くのがいいんだろうなぁ？何かヒントがあるかなぁ？」って思いながらこの本を開いた。先に書いておくと、ヒントはあった。 アウトサイドインのTDD 全然予想してなかったから、おー！と思ったのが、説明をTDDで進めていくってところ。好き

はじめに とあるセキュリティインシデントにおいて、サーバを電源ケーブルごと引き抜いたという対応が行われ、X（Twitter）ではこの対応について賛否両論が見られました。このうち電源を入れたままにすべきという人の意見には、「マルウェアの中にはシャットダウンすることで自分自身を削除し、感染痕跡を削除するものがある」「メモリを調査すべきなのでシャットダウンすべきではない」のような意見が見られました。 本記事では実際にメモリからどのような情報がわかるか、そしてメモリダンプを解析することの有用性と課題について記載します。 メモリフォレンジック セキュリティインシデントにおいてはフォレンジック調査が行われる場合があります。フォレンジック調査には、HDDやSSDのようなストレージを調査対象とするディスクフォレンジック、パケットキャプチャやNetFlow、ProxyやFWのログのような通信を対象とするネッ

Auto increment（自動採番）型を採用したくない場合 Auto Incrementは、データベースにおいて自動的に一意の識別子を生成するメカニズムです。通常、数値型の列が対象となり、新しいレコードが挿入されるたびにその列の値が自動的にインクリメントされます。典型的なIDですかね。 ここでは一意性の確保の話や、データ移行やバックアップのデメリットには言及せず、セキュリティとプライバシーの懸念にフォーカスして考えます。 予測可能性 Auto Increment型のIDは連番であるため、次に生成されるIDが容易に予測可能です。これにより、攻撃者がシステムの内部構造を推測し、不正アクセスを試みるリスクが高まります。 情報漏洩のリスク 連番のIDはデータベースの挿入順序を反映しているため、公開されることで企業の活動パターンやデータ生成の頻度が漏洩する可能性があります。 例） 競合他社は、公

メディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事は、MySQ

MIXI でモンストサーバチームとセキュリティ室を兼務している、atponsです。 モンストサーバチームでは、モンスターストライクとは別に、モンスターストライク スタジアムというスマートフォンのアプリゲームのサーバ開発・運用を行っています。 モンスターストライク スタジアムは、モンスターストライクとプレイスタイルは同じながら、4vs4の最大8人まで同時対戦や練習モードなどを備えたアプリになっており、モンストのeスポーツ大会「モンストグランプリ」を開催する際にも利用されています。 開発体制の現状 モンスターストライク スタジアムは、初期の段階でモンスターストライクのコードから分岐する形で開発されているため、アップストリームの変更を順次取り込んでいくという仕組みで運用されています。そのため、サーバコードなどは別にあり、適宜新機能を取り込んでいきアップストリームと合わせていくという開発・運用フロ

こんにちは、Sally社 CTO の @aitaro です。 マーダーミステリーアプリ「ウズ」とマダミス制作ツール「ウズスタジオ」、マダミス情報サイト「マダミス.jp」を開発しています。 はじめに この記事ではウズの開発当初から利用していた Docker Compose をやめることにした背景についてご紹介します。 Docker Compose は各マシンの開発環境での差異を吸収するというメリットがあり、多くの開発現場で導入されていますが、Docker Composeの抱えているデメリットを勘案して、最終的に一部を残して辞める決断をしました。 Docker Composeの特徴 Docker Composeは、複数のコンテナを定義し、管理するためのツールです。ウズの開発環境では、バックエンド、フロントエンド、データベースなどをそれぞれコンテナ化して、Composeで一括管理していました。こ