ChatGPT関連情報の追い方、個人・業務での使い方、サービスへの組み込み方、 ABEJAでの取り組み4例、ここ2週間のトピックなど行けるところまで
![Infrastructure-as-Code-is-very-tired](https://cdn-ak-scissors.b.st-hatena.com/image/square/fe6a48c8113fb60da02474eaa272b17524517767/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fa034beb9ba2b4485856f9bbe365a7487%2Fslide_0.jpg%3F11907273)
ChatGPT関連情報の追い方、個人・業務での使い方、サービスへの組み込み方、 ABEJAでの取り組み4例、ここ2週間のトピックなど行けるところまで
10年以上金融機関で働いているインフラエンジニアの落ちないサーバにするための考察です。 ハードウェアの専門家ではないので、正確ではないかもしれません。 今までの経験からの個人的考え方になります。 私たちオンプレ重視のインフラエンジニアは、 クラウドサービスではできない高可用性サーバを導入したり、 複数台構成で1台故障しても問題ない構成のサーバはコスト重視するなど、 システムに最適なサーバを導入しようとしています。 高可用性サーバを追求する目的 ■アプリに影響を与えないように Active/Standby構成にしていて、インフラ的にはダウンタイムが数秒だとしても、 アプリによっては復旧に時間がかかったり、問題ないことの確認にも時間がかかってしまいます。 また、正しくサーバが落ちればアプリが問題ないとしても、 サーバが中途半端な状態のままになってしまい、なんだかおかしいということもあります。
YAPC::ASIA Hachioji 2016 mid in Shinagawa
Googleが、太古のディストリビューションであるRed Hat 7.1から、10年新しいDebianベースのディストリビューションへ、ライブアップグレードした話を紹介する。 そのあと、自分の身の回りの環境と比較し、参考にすべきポイントを考察する。 原文は USENIX LISA の投稿論文だ。しかし、中身は論文体というよりは、事例の紹介といった適切かもしれない。 MERLIN, M. Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One. In Proceedings of the 27th conference on Large Installation System Administration (LISA) (2013),
インフラをアレしてる佐野です。トレタのコア部分はEngineyardで運用していますが、事業拡大に伴いサブシステムも増えてきました。新しいサブシステムは主にAWSで運用しています。そこで今回は事例として弊社の新規部分のインフラ運用のやり方、そこで使われている道具(Packer, Terraform, Serverspec, Ansible, Roadworker, Circle CI)、考え方などについて書きます。これらの道具はもはやよく知られたものであり、あまり真新しくはないとは思っています。しかしながら弊社に遊びに来た方や採用の応募者の方などからトレタのシステム運用に関する質問をいただくことがあり、その説明資料のかわりになるかな、という目的もあって書かせていただきます。これ以外にも道具はあるのですが、なんとなく興味をもってくれそうなワードをタイトルに羅列させていただきました。以下、目次
ウェブオペレーションエンジニアの id:y_uuki です。 はてなの東京オフィスで先月開催されたGo 1.6 Release Partyで、「Writing Tools in Go For Ops Engineers」というタイトルで発表しました。 発表では、最近作ったGo製ツールを紹介し、なぜGoがインフラエンジニアにとって良い言語であると感じているかを話しました。 最近作ったGo言語のツールの紹介 mkr Grabeni Droot gokc インフラエンジニアがGoを利用することのメリット 1. サーバへの配布が簡単 2. サーバ上で高速開発できる 3. 最終的に成果物をはやく作れる その他 発表資料 あとがき 最近作ったGo言語のツールの紹介 以下の4つのツールを作りました。いずれもはてなでのproduction利用を想定したものになります。 mkr mkrははてなで開発している
ニュース 「ディスクの信頼性を下げてよい」 GoogleがHDD業界にクラウド時代の提案 (2016/3/7 09:41) 次へ 需要爆発でコストが膨らむ 1 2 3 「データ損失の可能性が高くなってもよいので、キャパシティとシステムの性能にフォーカスしたディスクを」。巨大なデータセンターを世界で運用するGoogleが、こんな要望をブログに綴った。クラウド時代に合う新しいアプローチが必要というが、いったいどんなものか? この変わった要望にハードウェアベンダーは応じられるのだろうか? ディスクをグループ化してパフォーマンス改善 「Googleはデータセンター向けの新しいディスクを求める」。Googleのクラウド事業「Google Cloud Platform」の公式ブログが2月23日付で、こう題したエントリーを公開した。同時期に開催されていたイベント「2016 USENIX conferen
2015年2月24日 ヒカ☆ラボ発表資料 Webアプリケーション負荷試験実践入門 ■スライドの目的 負荷試験の重要性を認識して頂く 意味のある負荷試験を最短距離で行うための“段取り”を持ち帰って頂く 内容的には、主にAWS上のLAMP構成のシステムに対する負荷試験ですが、負荷試験ツールに依存しない全般的に通用する話を扱っています。Read less
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
dots. Conference Spring 2016 ゲーム開発の裏側 http://eventdots.jp/event/580344
主にアプリケーション開発者向けに、Linuxサーバ上の問題を調査するために、ウェブオペレーションエンジニアとして日常的にやっていることを紹介します。 とりあえず調べたことを羅列しているのではなく、本当に自分が現場で使っているものだけに情報を絞っています。 普段使っているけれども、アプリケーション開発者向きではないものはあえて省いています。 MySQLやNginxなど、個別のミドルウェアに限定したノウハウについては書いていません。 ログインしたらまず確認すること 他にログインしている人がいるか確認(w) サーバの稼働時間の確認 (uptime) プロセスツリーをみる (ps) NICやIPアドレスの確認 (ip) ファイルシステムの確認(df) 負荷状況確認 top iostat netstat / ss ログ調査 /var/log/messages or /var/log/syslog /
ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった
GitHubが1月28日のサービス障害の詳細を公開。停電により内部のChatOpsシステムも落ちて初期対応が困難に。Redisクラスタの復旧に時間 報告では、サービス障害はGitHub社内のChatOpsシステムも巻き込んで初期対応に時間がかかってしまったこと、一時的な停電がRedisクラスタの障害を引き起こしたため、その究明と復旧が作業の主な部分だったことなどが説明されています。 報告の要点をまとめました。 内部のChatOpsシステムも障害に GitHubのサービス障害は、すでに報告されているように、自社データセンターにおける一時的な停電が最初の原因でした。 At 00:23am UTC on Thursday, January 28th, 2016 (4:23pm PST, Wednesday, January 27th) our primary data center experi
インフラストラクチャー部の成田です。2015年10月現在、インフラストラクチャー部には私を含め7人のインフラエンジニアが所属しており、このメンバーでクックパッド本体サービスをはじめ様々な新規事業やいくつかの子会社のサーバを運用しています。私自身もエンジニアではありますが部のマネージャも兼ねているため、立場上、社外の方からインフラエンジニアのマネジメントについて質問されることがよくあります。今回は、私自身の考え方とクックパッド社における事例を紹介したいと思います。 「インフラエンジニア」とは 「インフラエンジニア」という言葉の定義はあいまいで、しばしば議論の的になります。傍目からは明らかにインフラエンジニアであるように見えるにも関わらず「私はインフラエンジニアでは無い」と主張する人たちもいます。このような状況になっているのは、サーバ運用に関する業務分掌が会社ごとに異なるからであると私は考えて
August 11, 2013 Immutable Infrastracture について / apatheia.info こちらのエントリーを読んでふと思いついたので書きました。 式年遷宮 / 伊勢神宮 今年、伊勢神宮は20年に一度の式年遷宮の年なのだが、 このシステム、今のインターネットのインフラストラクチャの モデルとして結構参考になるのではないだろうか。 さすがに20年間無停止で動いているサーバは その存在自体が重要文化財になってしまうが、例えば、1つのシステムを ロードバランサ、スイッチ、サーバ、ミドルウェア、ログ集約サーバなど 完全に冗長化しておき、1週間毎に冗長化されたシステム、A、Bをそれぞれ入れ替える。 このアーキテクチャを採用した場合、 アプリケーションの大規模な改修が発生した場合にも スタンバイ側となっているインフラストラクチャ側で スナップショットのようなものを取得
クラウドを活用した本番システムのデプロイ手法の1つに「Blue-Green Deployment」がある。Blue-Green Deploymentの目的とそのメリットを、マーチン・ファウラー氏の解説から紹介する。 1つ前の記事で紹介した、チャド・ファウラー氏によるImmutable Infrastructureの記事「Immutable Infrastructure(イミュータブルインフラストラクチャ)と捨ててしまえるコンポーネント」では、デプロイをより安心して行うために、サーバの内容を変更する際には既存のサーバに手を加えるのではなく、新規に作り直して切り替える、という方法を提案しています。これがサーバの不変性、すなわちImmutable Infrastructureにつながるわけです。 これから紹介するマーチン・ファウラー氏の記事「BlueGreenDeployment」は、Immut
クラウドを対象にした調査会社CloudHarmonyが、過去1年のおもなクラウドの稼働状況を明らかにしています。GigaOmが記事「Amazon Web Services tops list of most reliable public clouds — Tech News and Analysis」で紹介していますが、下記のCloudHarmonyのデータは誰でも参照できます。ここでは注目ポイントをざっと見てみましょう。 CloudHarmonyの提供しているサービスの1つ「CloudSquare」では、おもなクラウド(おそらくCloudHarmonyに申し込みをしたクラウドベンダ)の稼働状況をほぼリアルタイムに表示しています。これはサーバのモニタリングサービスを提供しているPanoptaの協力によって実現しているもので、Panoptaは60秒ごとにエージェントから情報を収集していると
はじめに これは ドリコムAdventCalendar の9日目の記事です。 8日目はsazae657さんによるドリコムの俺を支えるUIツールキットです。 自己紹介 @hiracy といいます。 ドリコムのインフラやってます。 最近発表したスライド ドリコムのInfrastructure as Code インフラ自動化とテストについて この内容について WEBサービス・ソーシャルゲームのインフラにてサーバが増加した時の管理について採用してきたツールとノウハウについて書かせて頂きました。 サーバ増加時の管理にお悩みのインフラ担当者は参考にしてみてはいかがでしょうか。 プロビジョニング 業者又は自前でラッキングされたサーバやクラウド業者で契約し使えるようになったサーバからOS設定・ミドルウェアインストール等を1台1台コマンドで設定すると日が暮れてしまいます。(たまにやってみるといい気付きがあり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く