サーバ作業を安全に行うための工夫
こんにちは。 2021年7月にハートビーツに入社後、エンジニアリンググループに所属している北岡です。 以前は同じMSP企業で10年以上勤務しておりましたが、自身のスキル向上などを目的としてハートビーツへ入社しました。 私の転職の経緯やハートビーツへ入社して感じたことなどは今後お話するとして、今回はお客様のLinuxサーバ上で作業する際、私がオペレーション中に意識していることやミスを防ぐために行っていることについて紹介します。 コピー、ペーストのショートカットキーを変更する コピー「Ctrl + c」とペースト「Ctrl + v」はキーが隣り合っており、タイピングミスによってコピーしようとしたつもりがペーストしてしまったということが起こりえます。 メモ帳などで起きた場合は特に問題にはなりませんが、サーバ上で起きると不要なコマンド実行に繋がります。小さなことではありますが防止策をとるべきです。
インフラエンジニアを20年やってて初めて知ったtopコマンドの表示を劇的に見やすくする方法 | 株式会社ビヨンド
こんにちは、カナダに来て1年弱ですが、いまだに"how are you?"にアイムファインセンキューと返してしまう全然英語が上達してない聖賢です。 インフラエンジニアならみんな大好きtopコマンド、おそらくビヨンドの中ではサーバ運用の中で最初に覚えるコマンドじゃないでしょうか。 実は結構奥が深いコマンドでいろんなことができるので、これまでドヤ顔で「こんなこともできるんやで」と上司の威厳、、、もとい先輩としての経験を後進に伝えていたのですが私も最近になって初めて知った超便利な使い方を紹介したいと思います。 ちょっと長いですがお付き合いください。 普通にtopコマンドを実行すると以下のような画面が表示されます 結構これだけでもサーバ運用には重要な情報が詰まっているのですが、topコマンドの見方などは他でも色々と紹介されていると思うので今回は割愛します 今回はこのtopコマンドの表示を最終的にこ
Amazon ECS でのコンテナデプロイの高速化
Amazon ECS でのコンテナデプロイの高速化 この記事は同僚の Nathan Peck (@nathanpeck)が書いた記事 “Speeding up Amazon ECS container deployments” を翻訳し、加筆・修正したものです. 元記事を ECS ユーザに紹介する機会が何回かあったので、せっかくなので翻訳することにしました. コンテナのオーケストレーションは非常に複雑な問題の一つです. アプリケーションコンテナのデプロイのために、相互にやり取りを行う複数の異なるコンポーネントが存在します. あなたのアプリケーションを実行したオーケストレータは、その実行されたアプリケーションが Web トラフィックを受け取る用意ができているかどうかについて判断する必要があります. その後そのアプリケーションはスケールダウンされたり、あるいは新しいバージョンのアプリケーション
なぜInfrastructure as Codeが必要なのか？ - プログラマの思索
最近ようやく、Ciscoのスイッチやルータの使い方が分かってきた。 GNS3上のルータやスイッチをCiscoコマンドで設定したり、動かしているうちに、ネットワーク技術の奥深さや難しさが何となく見えてきた気がする。 以下はラフなメモ書き。 間違いがあれば後で直す。 そもそも、ネットワーク技術の根本問題は何なのか？ 根本には、ネットワークは動いていて当たり前という高品質が前提の上で、コスト、高性能、冗長性、セキュリティというパラメータのトレードオフがあると考える。 コスト＝F（高い品質、高い性能、冗長性、セキュリティ）という複雑な方程式から、最小コストとなるパラメータの組み合わせを探そうとしている。 ネットワークの根本問題は何か～昨今のIT技術と時代の変化についての考察: プログラマの思索 ネットワーク技術の必要性が高まっている: プログラマの思索 ネットワークは動いて当たり前であり、通信でき
新人ITインフラエンジニアに役立つ学習リソース まとめ
まえがき IT業界で10年弱努めて見て、現在は教育部門にいることもあり”新人教育に向いている教材は有りませんか？”という質問を頂くことがあります。 昨今ITに関する様々な知識は情報が溢れていて、少し検索エンジンで調べれば大量のリソースにすぐアクセスができます。 一方で、本当に価値があるものも大量の情報の中に埋もれてしまいがちです。 本記事が目指すポイントとしては、”これからIT業界でインフラエンジニアとして頑張るぞ”という方向けが、短時間で良質なリソースにアクセス出来るようにすることです。(私自身のおすすめ色が強いです) なお、ここで想定する”インフラ”というのは次の要素を想定しています。 サーバ オペレーティング システム ストレージ ネットワーク 仮想化 パブリッククラウド ですから、次のようなカテゴリについては全く触れていない、あるいは触れていてもかなり部分的だと言う点をご理解下さい
【図解】初心者が知っておきたいサーバ周りの仕組みの話 - Qiita
※2021年 3月28日 更新※ たくさんの方にご一読いただき、ありがとうございます。お読みいただいた方からご指摘を賜った点をもとに記事を修正いたしました。修正・追記箇所は末尾をご確認ください。 サーバ周りの仕組みについて、初心者でも最低限知っておくべきだと感じた内容を整理しています。 ここでいう「最低限」とは、プログラミング言語を勉強し、何かしらアプリケーションを作成して、ユーザが利用可能な状態にし（デプロイ）、公開するうえで必要になる知識のことです。 「サーバ」とは何か ユーザの要求（リクエスト）に応じて、サービスを提供（レスポンス）するコンピュータやプログラムのことを「サーバ」と言います。 例えば、ユーザが「このWebページを閲覧したい」とリクエストしたら、サーバはそのWebページの表示に必要な処理を実行し、ユーザに返します。これによってユーザが使用しているブラウザに、Webページが
小規模（5〜20人）オフィスのネットワーク構築例
背景 株式会社マインディアCTOの@matsubokkuriです。 事業規模の拡大に伴いオフィスの移転がありました。それに伴い社内ネットワークインフラの構築しました。オンサイトで働く人は約10名。エンジニアは私1名なのでインフラ整備を自分でやるか外注するかという選択でしたが、外注するためにはRFP作るのが面倒だし費用がかかるのでDIYしました。 中小企業のネットワーク構築の記事は5年前の@wadapさんの記事が詳しいです。その記事以降、まとまった社内LAN構築の良い感じのノウハウ記事を見つけられませんでした。その5年の差分を埋めるためにも記録を書いておきます。 要求定義 ゲスト用ネットワークの分離（インターネット回線、LAN回線） 将来のシステム監査で指摘されるであろうことなので。 トラフィックのQoS制御のため。 インターネット上のホストにおいてグローバルIPアドレスによるアクセス制限が
2020年10月に発生した東京証券取引所のシステム障害についてまとめてみた - piyolog
2020年10月1日、東京証券取引所はアローヘッドの機器故障によりシステム障害が発生し、終日売買を停止すると発表しました。故障した機器は交換が行われ、取引は翌日再開されています。ここでは関連する情報をまとめます。 機器故障起きるも縮退運用に失敗 障害概要図 アローヘッド内の共有ディスク装置1号機で機器故障が発生した。実際故障したのはサーバー上のメモリ周辺機器とされる。 1号機故障により両現用で稼働していた2号機のみのフェールオーバー（縮退運用）が行われるはずだったが何らかの問題により行われなかった。 共有ディスク装置を使用する相場配信、売買監視のシステムで障害が発生。 障害復旧時に発生する注文データ消失による市場混乱を避けるため当日終日の取引停止の措置を実施。（遮断） フェールオーバー失敗原因は設定ミス フェールオーバーに失敗した理由が特定できたとして10月5日に発表。 障害発生時のフェー
AWS システム構築 非機能要件ヒアリングシートを公開してみた | DevelopersIO
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井 亮です。 日本国内においても多くのシステムがクラウド上で稼働していることと思います。 俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。 ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が本格化してきたというのが肌感覚であります。 クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。 クラウド上では出来ること出来ないこと
インフラど素人が1ヶ月半でKubernetes本番環境を作るまでの失敗の軌跡（奇跡） - Qiita
タイトル通りですが、1年目エンジニアのインフラのイの字も知らなかった私が1ヶ月半かけてKubernetesで環境構築するまでの失敗の軌跡です（そして環境構築できたのが奇跡）。 理想的にはこれを読めばインフラ初心者でもKubernetes（以下k8s）で環境構築できるところまで説明することですが、そういうわけでなく、環境構築の解説というより自分の失敗やつまづきポイント、役に立ったことをただただ書き連ねていきます。ただ他の初心者の方も同じようなところでつまづくこともあると思うので少しでもお役に立てたら嬉しいです。 バックエンド側で使った技術は以下になっています。 言語：Ruby（RoR） API：GraphQL インフラ：Azure その他：Docker、k8s 実際の実装でハマったところは各章の最後に教訓として簡単にまとめてはいますが、大事なことは先に結論として述べておきます。 Docker
Infrastructure as Dataとは何か
最近GCPから登場したKubernetes YAMLのPackage managerであるKptは「Infrastructure as Data（Configuration as Data）」という考えかたを基礎としてそれを推し進めようとしている．それ以外にもKubernetesのEcosystemには（明示はされていなくても）この考え方が中心にある．Infrastructure as Codeとは何が違うのかなど歴史を振り返りつつまとめてみる． （指針はBorg, Omega, and Kubernetesという論文にあるが「Infrastrcuture as Data（Configuration as Data）」という言葉を明確に定義した文章はない．この記事はReferencesに挙げるいくつかのPodcastにおける@kelseyhightowerの発言や，それに反応する@bgra
【入門】インフラやるなら知っておきたいトピックのリンク集 - Qiita
インフラをやるうえで知っておきたいトピックを独断と偏見で選んでリンク集をつくりました． HTTP HTTP入門 [BurpSuiteJapan]HTTP基礎入門 RESTful API Web API入門 RESTful API 入門 KVS key-valueストアの基礎知識 KVS 超入門 - footmark NoSQL HBaseの概要とアーキテクチャ | Think IT（シンクイット） Oracle Cloud Hangout Cafe - 明解! NoSQLの勘所 - Speaker Deck データベース 2018-11-データベース / 2018-11 database - Speaker Deck SQLをはじめよう - 初心者でもわかる、構文とデータ取得の基本 - エンジニアHub｜若手Webエンジニアのキャリアを考える！ RDBとNoSQLにみるDB近現代史 データ
障害から学ぶクラウドの正しい歩き方について考える - そーだいなるらくがき帳
AWSで大きな障害が発生したこの機会に、自分がクラウドと正しく付き合っていくために必要なことを考える。 piyolog.hatenadiary.jp ちなみに稼働率 99.99% くらいを目指していくために必要な事を考える。 必要な稼働率を見極める 今回は 99.99% くらいを目指すと言ったが、実際に自分たちにとってどのくらいの稼働率を目指すか？ということはとてもとても大切だ。 幸い、今回自分は影響がなかったが、本当に完璧か？と言われるとそうではない。 まず弊社の場合、マルチリージョンではないので東京リージョンが落ちたら落ちる。 これを許容できない場合に99.99%を目指せるか？というと正直厳しい。 しかしサイトの規模はそんなに大きくないのでデータサイズも現実的に転送出来る範囲で、コンポーネントも少なく、TerraformやAnsibleによって再構築しやすい状態は整っている。 そのため
まだTerraform使ってるの？未来はPulumiだよ
Lv：4 Exp：19011 プログラマー友の中釣りが一番上手、釣友の中インフラが一番得意、インフラ友の中猫が一番好き、猫友の中プログラミングが一番詳しい。 本当のInfrastructure as Codeを実現するPulumi インフラをコードにして管理する、所謂Infrastructure as Code(IaC)、特にクラウド上のインフラ管理はTerraformというツールがよく使われていると思います。クラウドエースでもインフラ管理にはTerraformを使用しています。しかし、このInfrastructure as Codeは本当のCodeではなく、Configurationです。今回は本当のInfrastructure as Codeを実践するPulumiというツールを紹介したいと思います。 Pulumiはまさにプログラミングでインフラを自動化する Pulumiは自分が好きなプ
インフラエンジニアの独り言、ストレージは盲点になりがち - orangeitems’s diary
インフラエンジニアの世界 IT技術者というと世間から見たら、要件定義やシステム設計をおこなうシステムエンジニアと、それを実装するプログラマーしか見えてないと思うんですよね。でもその基盤を動かすインフラエンジニアという人たちが全体の10パーセント弱（肌感）存在しています。 インフラエンジニアと言ってもまたそこから役割分担があって、物理サーバーやOSに強いサーバーエンジニアと、ネットワークに強いネットワークエンジニアがいます。大昔は物理サーバーとネットワークしかインフラに無かったので、大体はこの二極化でした。ネットワークエンジニアはスイッチやファイアウォール、ロードバランサーくらいまでは自分の領域としてくれていますが、OSやミドルウェアのことになると、それは私の領域ではない発言が出てサーバーエンジニアをブチ切れさせること請け合い。逆にネットワークエンジニアはサーバーエンジニアがなんでもネットワ
個人で運用するKubernetesクラスタ - k0kubun's blog
Kubernetesの使用感に興味があってaws-workshop-for-kubernetesというのを先週やり、ちょうどEKSがGAになった直後だったのでEKSが試せたのだけど、まあ最初からマネージドだとあまり面白みがないし金もかかるので、個人のVPSで動かしてた奴を全部Kubernetes上で動かすようにしてみている。 まだ本番で運用した知見みたいなのが貯まってるわけではないのだが、公式のドキュメントを中心に読んでいても単に動かし始める段階で結構ハマって時間を消費したので、これから同じようなことをやろうとしている人向けに備忘録を兼ねて使用感や知見をまとめておくことにした。 Kubernetesは今でもalphaやbetaの機能が多く、今後この記事の内容も古くなることが予想されるので、なるべく公式のドキュメントへのリンクを置くのを意識して書いてある。 構成 現時点で、ConoHaで借り
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
インフラ自動化の落とし穴と宣言的アーキテクチャ
インフラエンジニアway 2019年間アクセスランキング！
hatebu.me
自己修復的なインフラ -Self-Healing Infrastructure-
