Kubernetes、やめました | 外道父の匠
最近 Kubernetes 全然触ってねーなって思ってたところに、『6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない？となった話 – データエンジニアの酩酊日記』を見つけて、自分と異なる立場によるコンテナシステムへの感想を興味深く読ませていただきました。 Kubernetes を推す人がいる一方で、ここには昨夏『Kubernetes、はじめました』と言っておきながら今年に入って全然触らず、ECSを使ったシステムばっか手掛け、Kubernetes いらなくね？って思う人もいるわけで。これはいったいどういうことでしょう、と雑感タイムです。 どうしてコンテナシステムで迷うのか 最初に断っておきたいのは、以下 Kubernetes を否定したり腐すような意図は全くなく、なんでやろ？って自身に問いかけた私見です。やめました、と言ってもウチで今も使っ
Amazon Auroraを真に理解するための性能検証 | 外道父の匠
今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照／更新クエリを実行しています デ
現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠
RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね（ｷﾘｯ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした
MySQL5.7 / RDS / Aurora / Cloud SQL の性能比較 | 外道父の匠
CloudSQLの価格は実戦的という意味で、per Dayの価格を24hourで割った価格にしています。 メモリは2GBあれば検証としては十分なので格差は関係ありません。 IOPSはEBSならGeneral Purposeの1000GB*3で最大確保しています。 その他、ネットワーク周りなどポイントがあれば都度、補足していきます。 ベンチマークのデータ 今回、採取した全データはこちらになります。一部、目的に対して不要と判断したら省略しています。まぁ、こんなオレオレメモデータを見ても楽しくないでしょうから、１つ１つ考察していきましょう。 手法について 私がよくやる計測方法なのですが、innodb_buffer_pool_size がデータ容量より大きい健全な状態と、最小の16MBで過負荷ストレージを演出し、それぞれで参照／更新を別々にランダムアクセスをすることで、最初のボトルネックを炙り出し
書籍「たのしいインフラの歩き方」を執筆しました | 外道父の匠
エンジニアになってかれこれ14年目、そのうちの多くをインフラエンジニアとして過ごしてきました。ドリコムが弱小ベンチャーの時代から始まり、上場を経て今に至るわけですが…… そんな私の経験を凝縮したような書籍 『たのしいインフラの歩き方』 を執筆しましたことを、ご報告させていただきます！ 本の概要 タイトルどおり、インフラ周りの歩き方について記したものであるため、これを読めば環境を構築できるとか、深い技術や仕組みを理解できる、というようなザ・技術書といった類の内容ではありません。 では、ここでいう歩き方とはなんぞや？といいますと、起業したての小企業から、数百人規模の大企業に至るまでに、どのような技術的要望があり、どのように解決していくのか、という時間軸や規模感に沿ったインフラのエンジニアリングや、その心構え、ということになります。 対象読者としては、大きくは初～中級者のエンジニアとなっています
2014年からはじめるAWSリンク集 | 外道父の匠
ガチのAWSド素人が年末に調べまくった、AWS関連のリンク集です。 まだまだ調査中なので随時追加する予定ですが、広深くてキリがないのと、年始一発目の目覚ましエントリということでいってしまいます！ はじめた目的 多数のスタートアップにおいて、インフラ専門のエンジニアが付かなくても、小～中規模程度まではそのチームでインフラ面を完結できるようにしたい。 …ということで、今の時代に合わせて簡単・安価・拡張性・耐障害性…を満たす環境を考えるべく、ひたすら知識をかき集めることにしました。考えた構成などについては別途書きたいと思います。 また、遡って調べるほどに出来と進化速度に感心するとともに、情報消費期限がせいぜい２年だと感じ、ほぼ２年以内の情報をもってこのような臭ぇタイトルにしています。 目次 ドキュメント アーキテクチャ クラウド全般比較 クラウド性能比較 費用／スペック ネットワーク 基本インス
新卒インフラエンジニアを育成した話 | 外道父の匠
お久しぶりでございます。諸事情によって半年近くも息を潜めていましたが、また継続的なアウトプットをしていきたいと思います。あうとぷっとあうとぷっと。 昨年からAWSに触り始めて、少しずつ研究して、今年から本番運用を開始できています。なので、そっち方面が多くなりそうなのですが、その一発目として昨年にAWSを軸に新卒インフラエンジニアを育成してみた話を書いてみます。 経緯 ウチでは一般的な新卒採用を行っています。内定が出て、入社後はエンジニアも一定期間の研修を受けて、そして配属されることになっています。 私は稀に、キャリアプランによっては内定した段階の子との面談を組まされるのですが、その時点でインフラエンジニアになるという断固たる決意を持っていて、研修の段階に入っても意志は変わらなかった野郎がいたのでインフラ部隊に入れることにしました。しましたといっても普通は、配属は本人の希望以外に人事部判断や
Novaデータを共有ストレージに保存して live migration !! | 外道父の匠
風邪を引いて更新を滞らせたものの、技術メモだけは溜まっていくこのごろ。 live migration でVMを停止せずにHost間を移動させる、仮想環境の醍醐味から復活するとしましょう。 Cephをマウント live migration 機能はNovaデータの共有化が必須となります。貧乏なのでお金をかける場面じゃないので、共有ストレージはCephを利用することとします。マウントの仕方は前記事を参照してください。 このように全ComputeNodeでマウントしておいてください。 df -Th /mnt/ceph ファイルシス タイプ サイズ 使用 残り 使用% マウント位置 192.168.0.11:6789:/ ceph 5.4T 221G 5.2T 5% /mnt/ceph
Ceph基本情報と構築手順 | 外道父の匠
CephはLinux上で動作する分散ファイルシステム(Distributed File System)、ということでOpenStackのストレージに採用する目的で使い始めました。 まずは軽く基本インストール手順から記していきます。 選んだ理由 OpenStackに使うのに選んだ理由は色々ありますが… Cephの過去Verは不安定と言われていたが、最近はわりと落ち着いたらしい SwiftをGlanceだけに使うにはSwiftは扱いが重たい Cinderに高価な共有ストレージを使うつもりはない なんとCephはGlanceでもCinderでも使えるではないか Cephは冗長性／拡張性に優れているらしいのでHDFS経験者として好ましい ほぼ採用を決定していますが、重要な運用面はこれから検証していく状況になっています。 リンク 本家 Ceph本家 RELEASE NOTES 概要 ceph: di
Keystone＋LDAP＋LAMでOpenStack管理 | 外道父の匠
Quantum周りのたった１つの問題に１週間以上ハマって絶望するも、 絞りだすような勘で生還してブログ再開！！ 今回はなんとっ！KeystoneデータをLDAPで管理するという一風変わった情報をお届けします！ LDAPを採用した理由 どうしてわざわざLDAPにしたのか、というと、 まず、既にLDAPが存在し、他の複数のソフトウェアのアカウント管理に用いていたため、OpenStackも同様に既存のLDAPユーザでログインしたかった、というのが１つ。 次に、LDAPユーザから削除された（例えば退職したとか）場合に、そのユーザが管理していたVMを自動的に（もしくは一括して）削除できるようにすることで、VMをより管理しやすくしたかったから。Horizonの表示上は見えませんが、実は novadb.instances テーブルには user_id が保存されているし、nova-manage vm l
OpenStackでつくる開発環境と外道塾 発表資料 | 外道父の匠
7/23（火）に、弊社カフェにてgloopsさんと勉強会を開催しました。 今回、私はOpenStackについて、こんな風に使ってますよ～という内容で発表させて頂きました。その資料がこちらになります。 補足 就活 冒頭で、『就活に役に立たない』とぶっ込んでしまいましたが、 採用面接の際に、「OpenStackを構築したことがあります！」のコメントで うん、コイツは厳しい道をやり遂げる根性はあるな！とポイントアップして 採用に至った例を聞いてしまいました。 なので、皆さん、もっとOpenStackを触って情報を公開して自慢していけばよいと思います！ 社内で既に使ってもらっていますが、ほぼ不満なくいっぱい利用してもらえています。 長く使う開発環境としてはもちろんですが、 ちょっと調べたい時に、起動して即ポイできるのも想像以上に魅力的なようです。 格好つけて多くのOSを用意していますが、 弊社では
エンジニアがアウトプットすべき理由 | 外道父の匠
ブログが流行りだして10年以上が経とうとしているのに今更な内容ですが、エンジニアがブログを書く書かないについて再考する機会があったので、書き留めておきたいと思います。 書く人にとってはメリットがわかってるし、書かない人にとってはデメリットを流せるし、ぶっちゃけ好きにすればいいだけではあるのですが・・・ アウトプットとは ”発信”の方がしっくりくるのでどっちも使いますが、ここでは一般的っぽい”アウトプット”としています。私が思いつくアウトプットとは、 技術ブログを書くこと Wikiに手順やバッドノウハウをまとめること Twitterやコミュニケーションツールで短文メッセージを投稿すること 登壇発表すること 講師やメンターとして育成すること 書籍や連載を執筆すること ソースコードを公開またはプルリクすること で、どれも社内／社外どちらでも問わない、といったところです。ただし、社内におけるコード
OpenStackのpolicy.jsonを個別ユーザ仕様にする | 外道父の匠
コンポーネント毎に設置されている policy.json ですが、デフォルト設定だけでも多いのに、隠れ設定もいっぱいあるため把握するのが非常に面倒くさいです。 が、デフォだと他人が作成したVMを勝手に削除したり色々できてしまうので、 グッと我慢して、隠れ設定のページを見つけたり、他人のVMをイジれないようにしました。 Nova 目的は、別ユーザが作成したVMを削除したり、コンソール覗いたり、Volumeを弄ったり、スナップショット取ったりできないようにすることです。参考にしたページはこちら Re: [rhos-list] Control Access to instance termination /etc/nova/policy.json "admin_or_user": "is_admin:True or user_id:%(user_id)s", "compute:attach_vo
OpenStack Grizzly構築 on Wheezy (2) Open vSwitch | 外道父の匠
それでは続いて、皆大好き・恐怖のOpen vSwitchの設定になります。 初見は、カザーブの東にお散歩に行ったら突然エンカウントしたグリズリー級のわけわかめなシステムですが、慣れたら大丈夫っていうか、自分にとっての正解を見つけてしまえばあとは元気にスルーするだけなので頑張りどころだったりします。 事故事例 Open vSwitchの設定は、NICの数やQuantumの設定（ブリッジマッピングなど）によって正解は変わってくるのですが、ミスった時はだいたいこのような現象になります。 ovs-vsctlコマンドで設定したらプライベートネットワークすら繋がらなくなった VMに接続できない ホスト間をまたいだVM同士の接続ができない VMがDHCPアドレスを取得できない（参考：OpenStackのDHCP問題まとめ） GREパケットでフラッディングが起きる（参考：OpenStack Open vS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
