春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubやGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で
はじめに タイトルはこちらから拝借しました。この記事は他のパブリッククラウド(Azure, GCP)を薦める記事でもなければ、プライベートクラウドを薦める記事でもありません。また私自身、エンジニアキャリアの中でAWSはたくさん使ってきましたし、今でもソフトウェア開発のわがままに答えてくれる素晴らしいサービスだと思っているので、AWSを貶めるような記事でもありません。むしろ以下に紹介するサービスはAWS上に構築されていることが多く、間接的にもますます世界中の基盤として発展していくはずです。 PaaSアーキテクチャ 前提条件 前提として、現在でも主流なSPAを中心としたフロントエンド、バックエンド、データベースサービスからなるアプリケーションを想定します。 この場合、 フロントエンド → CDN + Static Hosting バックエンド → Container Deploy(Auto S
AWSのインフラを運用・監視する上で使いやすいと思ったサービスを組み合わせて構成図を作成しました。それぞれのサービスの簡単な説明と類似サービスの紹介、また構成の詳細について説明していきます。 (開発で使用するようなサービスも紹介しますが、あくまでも運用・監視だけの構成です。) 各個人・企業によって環境は違うと思いますし、使いやすいと思うサービスは人それぞれだと思うので、これが正解という訳ではありませんが、参考にしてただければ幸いです。 参考になった教材を紹介した記事も作成しました。是非読んでみてください! 【AWS】さいきょうの運用・監視構成を作成するのに参考になった書籍 インフラエンジニア1年生がプログラミングを勉強するのに使った教材 全体図 こちらがAWSにおける"ぼくのかんがえたさいきょうの"運用・監視構成です。複雑で分かりづらいかと思うので、詳細に説明していきます。最後まで読めばこ
はじめに 昨年、AWS のインフラを運用・監視する上で使いやすいと思ったサービスを組み合わせて構成図を紹介した記事、「【AWS】ぼくのかんがえたさいきょうの運用・監視構成」が投稿したその日の Qiita のトレンド 1 位になり、はてなブックマークのテクノロジー分野でトップを飾りました。(たくさんの方に見ていただき感謝してます!) 本記事では「ぼくのかんがえたさいきょうの運用・監視構成」の続編として「ぼくのかんがえたさいきょうの DevOps 実現構成」を紹介させていただきます。あくまでも「ぼくのかんがえた」なので私個人の意見として受け入れていただけると助かります。 前回の記事でもお伝えいたしましたが、各個人・企業によって環境は違うと思いますし、使いやすいサービスは人それぞれだと思うので、これが正解という訳ではありません。一個人の意見として参考にしてただければ幸いです。 また、こちらの記事
2024年1月時点のAWSベストプラクティスに従って作成しました 好評でしたら続編も検討します 1. 環境ごとにアカウントを分離する 本番、検証、開発ごとにアカウントを分割しましょう ✕良くない例 ◎良い例 最初にアカウント分割しておかないと、後で分割するのはとても大変です アカウントを分割することで「検証と思って作業したら、実は本番だった」のような事故を減らすことができます コストがアカウント単位で集計されるため、環境ごとのコストを簡単に算出することができます AWS Organizationsを使用することで、各環境に応じた権限設定が簡単にでき、ガバナンスを強化することができます AWSアカウントはAWS Control TowerのAccount Factoryを使用することで、クレジットカード情報を都度入力することなく簡単にアカウントの払い出しが可能です また、AWS Contro
技術選定、してますか? こんにちは!エンジニアリングマネージャーの佐藤(@unsoluble_sugar)です! 今回は開発関連のライブラリやアセットを導入する際に、個人的に見ている技術選定過程のポイントについて書き残してみることにしました。 エンジニアであれば様々な場面で技術選定の判断を求められるかと思います。フロントエンドやサーバサイド、ネットワーク・インフラ構築、CI/CDといった開発領域。OS、言語、フレームワーク、開発ツール、SaaS、プラットフォームetc... 挙げだすとキリがないですよね。 個人開発等でユーザーの母数が小さかったり、運用期間が短く影響範囲が軽微な場合はそれほど気にしなくて良いかもしれません。一方で、企業としてシステム・アプリ開発をする上では、開発して終わりではなく中長期での運用保守が前提となりますので、サービス継続のための様々な点に注意しなければなりません。
本記事は BASE アドベントカレンダー 2023 の5日目の記事です。 はじめに こんにちは。 Shop to Shop チームでマネージャーをしている髙嶋です。 役割としてはエンジニアリングマネージャー(以下 EM)と言われるものを想像していただくとイメージしやすいかもしれません。 そんな私から、開発チーム内で取り組んだ10個の実験もとい取り組みについてご紹介させていただきます。 開発プロジェクトを遂行するチームの開発現場をスコープにした話になりますが、一つでも参考になるものがあれば幸いです。 ちなみにチーム構成としては PdM 1名、デザイナー1名、エンジニア5名、EM 1名(私)の総勢8名となります。 最後まで読むのが億劫になる可能性もあるので、この記事で伝えたいことだけ先に列挙しておきます。 出社(オフライン)とリモートワークの使い分けが難しいためにチームとしての活動はリモートワ
本書には、バックアップ、アーカイブ、リストア、リトリーブ、それらを行う上で用いられる手法、ソフトウェア、サービス、バックアップとアーカイブを保存する際に使用されるハードウェアなど、データ保護に関して必要な知識が全て詰まっています。この20年間に現れた新技術についても触れ、従来のバックアップから最新のIT技術までそれぞれの良い点と悪い点を理解することができます。「バックアップとアーカイブの違い」「テープがあるべき場所」「Microsoft 365やSalesforceのようなSaaS製品をバックアップすべきか」といったバックアップ業界で議論される多くのテーマにも決着をつけています。データ保護に関する決定を下すための重要な基本概念を学べる1冊です。 訳者まえがき 序文 はじめに 1章 データへのリスク:我々はなぜバックアップするのか 1.1 人災 1.1.1 事故 1.1.2 悪いコード 1.
CentOS6のOpenSSHが古い問題でいろいろ大変です。 CentOSのデフォOpenSSH(5.3p1)はちょっとアレなんで最新版(7.1p1)をコンパイルしてみたでかなり詳しく正確に書いてくれているのでなになんですが、ちょっとリマインドで書いておきます。 今回既存のSSHが5.3で7.5にバージョンアップしたという感じです。CentOS6やRedhad系だったらそこそここのやり方でOKな筈。 OpenSSH_5.3p1 ↓ OpenSSH_7.5p1 しかし結果からいうとtelnetや最近のクラウドサービスのコンソール的なものでSSH以外で接続しておかないとちょっと怖い感じがあります。 とはいえきちんと設定しればSSHの再起動で接続は切断されますが、すぐにSSHログインができるようにはなります。 バージョンの確認 http://ftp.jaist.ac.jp/pub/OpenBSD
はじめに ベンチャー企業や立ち上がって間もない開発組織の場合、事業の成長スピードに対して、インフラ/SREエンジニアへのリソース不足が発生します。 スピード重視の結果、監視設計が不十分なままプロダクトがリリースされることも少なくないため、インフラに強いベテランの方のみが障害対応に当たらざるを得ず、周囲はただ応援するといった形もあるのではないでしょうか。 いざというとき、「アプリケーション起因じゃなければ、私は何もわからない...」とならないために、非インフラ/SREエンジニアでも最低限覚えておきたい障害発生時に役立つ監視系のコマンドをまとめてみようと思います。 本記事で想定している読者は以下の通りです。 インフラ関連の障害時に、問題の切り分けを行うためのコマンドが知りたい人 監視系コマンドを実行できる環境構築をサクッと作って動かしながら学びたい人 非インフラ/SREエンジニアでインフラ起因
Overview of Twitter Fleet Twitter came of age when hardware from physical enterprise vendors ruled the data center. Since then we’ve continually engineered and refreshed our fleet to take advantage of the latest open standards in technology and hardware efficiency in order to deliver the best possible experience. Our current distribution of hardware is shown below: Network Traffic We started to mi
こんにちは。メディアサービス開発部Webアプリケーション開発課の奥川です。ニコニコ漫画のバックエンド開発を担当しています。 2021年初頭、ニコニコ漫画である作品の連載が開始されました。それに端を発する数カ月間のサーバ障害により、ユーザーの皆様には大変ご迷惑をおかけしました。 少し前の話にはなりますが、当時ニコニコ漫画のサーバでは何が起こっていたのか、どのような対応を行ったのかを振り返ってみたいと思います。 1号棟(事の起こり) 2021/01/08 問題の作品(以後、「作品I」*1と記述します)の第1話が投稿されます。その過激な内容からSNSなどでは一部で話題になりましたが、まだニコニコ漫画へのアクセスも穏やかなものでした。 2021/01/22 その2週間後、「第2話(前編)」の公開から事件が起こります。 ピークタイム最中の12:22頃から、まずmemcachedがCPU Utiliz
ホワイトリストの導入について 知っている仲間内だけで遊びたい場合など、知らない人が勝手にサーバに入ってくることを防ぐことが出来ます。 荒らしユーザからの被害を防ぐにも効果があります。 ホワイトリスト設定 ホワイトリスト設定を有効にするための方法として、下記の方法がありますのでそれぞれについて説明していきます。 サーバコンソールから設定 Minecraftクライアントから設定 server.properiesを編集して設定 サーバコンソールから設定 「Minecraft_server」が動作しているサーバのコンソールから、「whitelist on」コマンドを実行することでホワイトリストを有効にする事ができます。 whitelist on 「whitelist on」コマンドを実行 「whitelist on」コマンドを実行すると、「Turned on the whitelist」のメッセー
この記事は2021年3月6日に行われたオープンソースカンファレンス 2021 Online/Springにおける発表を文章化したものです。 今回は「今日から始めるPrometheusによるシステム監視」ということで、Prometheusというツールについてご紹介をしていこうかなと思います。皆さんに「Prometheus完全に理解した」と言えるようになっていただきたい、というのが今回の目標です。 本連載は3本で構成されていて、それぞれ以下の内容を扱います。 Prometheusの特徴とアーキテクチャ(この記事) PrometheusとCNCF、Observability Prometheusを使ってみよう Prometheusとは Prometheus(プロメテウス)は、SoundCloudという海外の音楽系サービスのエンジニアによって開発された監視システムです。もともと、Kubernete
これまでスクリプトをデーモン化するために daemontools をよく使っていたのですが、同じコマンドを複数プロセス起動させたいときに煩雑というか、そもそもこのやりかたあってんの? って思ったので、代替になりそうなものをいくつか試しました。 例として、w1.sh と w2.sh の 2 つのサービスを、w1.sh は 2 プロセス、w2.sh は 3 プロセス起動したいものとします。 daemontools http://cr.yp.to/daemontools.html 定番 下記の SRPM から入れるとインストールが簡単 http://www.qmailtoaster.com/ 1サービス=1プロセスが基本 複数プロセスを起動したければその数だけサービスを定義する必要がある もしくはサービスとして起動したプロセスでさらにプロセスマネージャーみたいにするか # インストール sudo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く