読者です 読者をやめる 読者になる 読者になる

befs_anneの日記

インフラエンジニアとして多少マシになっていく記録(予定)

データベーススペシャリストを目指して勉強し始めて途中帰宅するまで

DBを受けた動機

ネスペにすら合格できない程度の専門性ではこの先生き残れないと思ったので、何か別の強みを持っておこうと思った。

勉強の過程

3月上旬からテキストを少しずつやってたら、 いつの間にか試験一週間前だった。 過去問題集に手を付けたのは4月10日で、午前Ⅱはチョロかったものの午後Ⅰ・Ⅱはろくに手を付けられず。

試験

午後Ⅰ

免除。次の春期試験まで?

午後Ⅱ

十中八九パスしている。考えても分からないような問題も1問ぐらいしかなかった。

午後Ⅰ

問1と問2を選んだけど、問1が終わった段階で既に時間を半分以上使っていて、問2のデッドロックの問題でフリーズしてそのままタイムアップ。

午後Ⅱ

敗因

安定の午後対策不足。同じ失敗を何度繰り返すのか……。

対策

午後Ⅰ・Ⅱの対策をちゃんとやる(特に午後Ⅱ)

これに尽きる。午後Ⅱが精神的にキツ過ぎるので、はじめは1問丸ごと片付けようと思わずに2日で1問やっつけるぐらいの心づもりでやる。

テキストに時間かけない

知り合いにテキスト読まない(読んでも1回、ノートはとらない)で問題集だけやる人がいるんだけど、私は理論を頭に入れてアウトプットに臨みたくなってしまうタイプでどうもテキスト→問題集のクセが染みついてしまっている。「問題集でよく出るところをテキストで抑える」のほうが効率がいい場合が多そう。いかにテキストを妥協できるか?いかに問題集での不正解の連続に耐えられるか?が私の資格試験全般に言える課題だと思う。

感想

DBについて

データベースを触ったことがない状態からのスタートだったので全てが新鮮だった。「候補キーを全て答えよ」とか「リレーションシップを完成させよ」系の問題で完全正解した時のカタルシスは、とにかくIPAのご機嫌取りに終始させられるNWにはない。ロジックだけで点が取れる優しい世界。

勉強の取り組み方

自身の勉強の取り組み方を見直す良い機会だったとポジティブに捉えておく。これで何かを変えないと本当にタダのグズ野郎なので、秋期のNWは テキストやりません。

Cybozu Meetup #2 SRE に参加してきた

概要

資料

docs.com

所感

顧客の増加傾向から見る設備投資

サイボウズは顧客の増加が単調(スライド27枚目)。サービスの需要予測が容易なので、無駄な設備投資の恐れがないんだそう。インフラって開発やデザイナーと比べるとビジネスが見えにくいから、たまにビジネスの傾向(サイボウズの場合は安定した顧客増)がインフラの領域に現れてくるのが新鮮で嬉しかったりする。私だけ?

オンコール当番制を可能にする要素

私がSREという試みにおいて関心を寄せていることのひとつに「如何にして夜間対応の準備をするのか?」があるんだけど、サイボウズはメルカリ同様2人1組でのオンコール当番制を採用しているとのことだった。

サイボウズのSREの皆さんはタレント集団という感じ(まさに「フレンズによって得意なことは違う」)で、「当番の2人ともが(スキルセット的に)対応できないことってないの?」って聞いたら「切り分けやプロセス再起動など最低限緊急対応に必要な水準は全員が満たすようにしている」とのこと。SRE Tech Talksでも思ったけど、オンコール当番制がきちんと回るかどうかって「最低限緊急対応に必要な水準=標準スキル」が定まっているかどうかが大きな要素だと思った。できることとそうでないことが人によって違う→2人ともできないから当番じゃない人叩き起こそう、なんてことが横行するようだとそうとう無理がある。

会社の制度によるサポートもまたポイントだと思っていて、メルカリもそうだけどよく夜間対応手当とか自宅勤務とかスピーディに導入できるよなあと思う。開発したツールのOSS公開について「ナレッジの公開って会社としてハードルないんですか?」って聞いたら@ymmt2005さんが「私が会社ですから」って言ってたのには超シビれた。"技術部署の偉いさんが技術の人である"っていう当たり前に思えるようなことが、こういうことを可能にするんだろうなー。弊社に合掌。

その他

  • 夜景きれい。27階すごい。
  • 本たくさん。ボドゲもたくさん。
  • 調達額すごすぎてボリュームディスカウント効きまくってるっぽい。標準PCのメモリが32GB?ストレージはMVNe 512GB?世の中じゃメモリ8GBが人権(最近16GBに上がった?)なんて言われている昨今、32GBものメモリを「標準」として乗っけられるサイボウズ、すごい。
  • テッキーな話もいいけど、ことSREに関しては今回のような仕組みの話のほうも気になっているので、色んな会社でSREチームが発足して、立ち上げノウハウみたいなのがある程度テンプレ化するといいなと思った。
  • ちょっとだけ期待していたネットワークの話はなかった。懇親会で少しお話聞けたからよかったかな。新卒の方(自分からSREチームを志願したらしい。すごい)もネットワークの自動化とかやっていきたいっておっしゃっていたと思うので、もし実現したら是非お話聞きたいです。

ホストであるサイボウズの皆さんだけじゃなくて、参加者の方ともたくさんお話できてよかったです。ありがとうございました。

フランクに原典にあたるということ

概要

最近RFCを読み始めた人の所感。

TL;DR

何らか調べものにおいて「原典にあたる」ということをはじめて教わったのは、マッキンゼー卒業生の人が書いた本だった。 これだったかな?

https://www.amazon.co.jp/マッキンゼー流-入社1年目問題解決の教科書-大嶋-祥誉/dp/4797369531www.amazon.co.jp

その頃はまだ前職に在籍していて、そんなに歳も変わらないのにかなり仕事のできるネットワークエンジニアがいた。彼はトラブルが起きた時の解決の手段として「RFCを読む」という選択肢を持っていて、ベンダマニュアルレベルで一通りの手段を試しても問題が解決しなかった場合、RFCに目を通してプロトコルの動きを確認していた。「当たり前だろ」と思う人もいるんだろうけど少なくとも私はそうじゃなくて、純粋に「すげーなこの人」と思っていた。

何が「すげー」かったのか?

純粋に「RFCを読む」ためには少なくとも英語が読めなきゃならない。今でこそ私も技術英語に慣れてきて、ベンダのKBぐらいならある程度の速度で読めるようになったものの、当時は今以上(以下というべきか)の英語弱者だったし、RFCはものにもよるけどボリュームがあるうえ抽象的な表現も多いし、トラブル発生時というのは通常業務に比べてインプットにかけられる時間も限られるので、そのスピード感の中であれを読むという選択肢は私は選べなかった。Google先生とベンダ、テクサポ頼み。エンジニアとしてはあまりかっこよくない。

最近の話

最近は業務に余裕が出てきたことと、もっと英語に慣れなきゃいけないということ、そしていい加減Google先生および「ネットワークエンジニアとして」離れをしなきゃならないという思いから、新しい技術に触れる時はRFCを読むようにしている。

しかし、RFCだけでそのプロトコルを理解しようとするのは中々にキツくて、他の日本語のドキュメントを参照してみたり、ツールを利用して少しでも読みやすくしたりしながら少しずつ読んでいる。

フランクに原典にあたるということ

はっきり言って今の私にとって原典(RFC)にあたるというのは結構なストレスだ。それでも、理解や問題解決の手法として「それ」を選べるということは、(業界で必須かどうかは一旦どうでもよくて)自意識のレベルで必要なことだと思っている。当たり前のようにRFCを読むということを選択できる彼のようには未だになれていないけど、いつか必要になる時のために、ヘルパーを頼りつつ目を通してみるのも悪くないと思う。

フランクに原典にあたるために使っているもの

「マスタリングTCP/IP」シリーズ

業界に飛び込んだ頃からの付き合いだけど、このシリーズの偉大さをあらためて思い知らされている。

www.amazon.co.jp

Google Dictionary Extension

ダブルクリックで単語を翻訳してくれる優れもの。Google翻訳が格段におりこうさんになったのは聞き及んでいるが、ページ丸ごと翻訳はしないという鉄の掟を守っている。

chrome.google.com

RFC読書会

……なるものをたまに見かける。気になる。一回身内(弊社内or同業の友人達)でやってみる?

Tremaで遊んだ

概要

Tremaで遊んだ。

Tremaとは

OpenFlowコントローラのプログラミングフレームワーク。 詳細は以下参照。

trema.github.io

TremaでOpenFlowプログラミング

プログラミングフレームワークとは

私のようなネットワーク土方には「プログラミングフレームワーク」という言葉がピンと来なかったのでググってみた。RubyだけでOpenFlowを動かすよりもTremaを挟んでやったほうが簡単に済むように、特定の機能・プロトコルを抽象化してとっつきやすくしてくれるものっぽい。前述のtrema-bookにも解説があるので併せて参照。

blog.codecamp.jp

遊んでみて

OpenFlowが一番バズってた頃は「ネットワークエンジニア絶滅の危機」な感じだったので毛嫌いしていたが、いざ遊んでみると面白いやつだった。こいつとだったらうまくやれそう。まだまだ本質的な使い方をしていないので、これから細々とやっていきたい。

にしても、我ながらPythonやったりRubyやったり忙しい。プログラマというのはそういうもんなんだろうか?

RXアクセラレーション(というかNICオフロード)が悪さをすることがあるらしい

概要

NICが持つRXアクセラレーション系の機能が、通信のパフォーマンスに悪影響を与えるケースがあるらしい。

RX アクセレーション (GRO、LRO、TPA など) を持つ NIC が、パフォーマンスが悪い TCP の影響を受ける場合がある - Red Hat Customer Portal

https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2090294

RXアクセラレーションとは

トラフィック受信時に発生するソフトウェア(CPU)処理を、ハードウェア(NIC)に肩代わり(オフロード)してもらっちゃおうという機能。「アクセラレーション」という言葉はよく出てくる(SSLアクセラレーションとか)けど、基本的にはハードウェア処理にすることを指すと思っておけばとりあえずよさそう。

LRO(Large Receive Offload)とは

セグメンテーションされたTCPパケットの構築をNICにやらせる。

Large receive offload - Wikipedia

GRO(Generic Receive Offload)とは

Red Hat Enterprise Linux 6 の低レベルネットワーク実装は、Generic Receive Offload (GRO) のサポートをその特徴の1つとして収納しています。 GRO システムは、CPU で実行されるプロセッシングの量を低減することにより来信ネットワーク接続のパフォーマンスを向上します。GRO は Large Receive Offload (LRO) システムと同じ技術を実装しますが、より広範囲のトランスポートレイヤープロトコルに適用できます。

解説だけ見ると、LROの上位互換に見える。

https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Release_Notes/networking.html#idp11696352

TX(送信)もあるでよ

TSO(TCP Segmentation Offload)やGSO(Generic Segmentation Offload)のように、TX(送信)オフロード機能も存在する。

TSO(TCP Segmentation Offload)の無効化 - Knowlege Database

オフロード系機能まとめ

Redhatのナレッジを見るのが話早そう。

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/network-nic-offloads.html

付き合い方

ネット上には送受信どちらにおいてもOFFにせよという記事が多い。

【CentOS7】オフロード機能まとめ – ZacoDesign

そんな中、以下のような情報もある。

uzy-exe.hateblo.jp

速さを追い求めるのでなければ、OFFが吉?

SRE Tech Talks #2に参加した

概要

「SREとか超かっけえ」という生半可な気持ちで「SRE Tech Talks #2」なるイベントに参加して思ったこと。

SREとは何なのか

TLに流れてくるSRE関連ツイートから「SRE=超できるインフラエンジニア、または彼らによるエンジニアリング」ぐらいの定義をしていて、あぁなんて高い山だろうと勝手につらみを感じていたんだけど、最初のセッションでメルカリの@cubicdiyaさんがSREのミッションをオペレーションとソフトウェアエンジニアリングの2つにシンプルに定義してくれて、SRE(する)とは?っていうモヤが少し晴れた。Googleが公開したドキュメントも読み込んでみようと思う。英語苦手だけど。

Google - Site Reliability Engineering

技術が資本

登壇者の方々や懇親会でお話しした方々は皆スキルフルで、やっぱりSREも技術があって、その上で何をするか、なんだなと思った。On-Call Engineeringは目から鱗。他の登壇者の方のセッションも、DBチューニング、サーバクラスタリング、バックアップ技術など、同じSREという括りの中で、裾野の広さを感じさせられた。

制度も大事

@cubicdaiyaさんのセッションの話ばっかりだけど、制度設計や会社の理解も重要だと思い知らされた。「皆電車乗ってたら困るから、On-Call当番は他のメンバーが出社した後に遅れて出社する」とか、On-Call対応期間中の手当とか。

ネットワークエンジニアから見たSRE

Site Reliabilityっていうぐらいだから、やはりWeb/DB/Appのウェブ系三銃士(人によってはリバプロが加わる)の話がメインだった。やっぱりまだまだサーバサイドの修行が足りない。特にMySQLの話なんかチンプンカンプンだった。

インフラエンジニアに囲まれて仕事をしているからなんとなく自分もインフラエンジニアという括りにいれてしまいそうになるけど、実際のところ未だにネットワークエンジニアしている。それも昔ながらのネットワーク屋って感じの。同じようなことをしている人達を貶めるつもりは一切ないし、ネットワークは好きだから、私はネットワークのためにコードを書いて、ネットワークのためにAPIを叩きたい。

そんななので、イベント中「ほとんど(と言うか全く?)ネットワークについて誰も話さないけど、ネットワークってSite Reliabilityには関わってないの?」と思ってしまう。ネットワークエンジニアの視点から見たSREもまたオツだと思うので、ぜひ聞きたいし、私も話したい(でも自社の事例を話せるようなフランクな会社でないのがつらいところ)。

Windows10のVagrantでJuniper Fireflyを動かすまで

概要

このQiitaの投稿を見て思い立った。一筋縄ではいかなかったので、手順を残しておく。VagrantVirtualBoxはインストール済み。

qiita.com

手順

boxをダウンロード

vagrant box add firefly121X47D154 https://atlas.hashicorp.com/juniper/boxes/ffp-12.1X47-D15.4

Vagrantfileの生成と編集

ディレクトリを作ってvagrant initする。vagrantディレクトリは作成済み。

cd vagrant
mkdir firefly01
cd firefly 01
vagrant init firefly121X47D154

記事で紹介されていた通りに編集。

vim Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
    config.vm.box = "firefly121X47D154"
    config.vm.define :firefly01 do | firefly01 |
        firefly01.vm.hostname = 'firefly01'
        firefly01.vm.network "private_network",ip: "192.168.33.1",netmask: "255.255.255.0"
    end
end

VMを起動

vagrant upでVMを起動しようとしたら、プラグインをインストールするよう言われたので素直にインストール。

vagrant up # 以下プラグインのインストールを要求される
vagrant plugin install vagrant-host-shell
vagrant up # 以下プラグインのインストールを要求される
vagrant plugin install vagrant-junos
vagrant up # 成功

vagrant statusで確認すると、無事runningに。

Fireflyにログイン

ここで問題発生。記事ではvagrant sshでログインするが、Windows10にはデフォルトでSSHクライアントが入っていないためvagrant sshができない。bashからもSSHを試したがこれも不可(公開鍵認証しか許可されていないから?)。

①Git for Windowsをインストール

最初のトライでやった対応。以下の記事を参考にGit for Windowsをインストールする。

d.hatena.ne.jp

ホームに作成されたアイコンをダブルクリックして開いたプロンプトからVagrantfileがあるディレクトリへ移動し、vagrant sshする。インストール時にWindows標準のプロンプトを使用するよう指定したが、反応が非常に悪い。

bash on Ubuntu on Windowsからログイン

先ほど試したらうまくいったので併せて記載しておく。vagrant sshは公開鍵認証を利用してSSHログインするわけだが、前述の通りWindowsにはデフォルトでSSHクライアントはない。しかし、秘密鍵はしっかり作成してある。以下のコマンドで出力される「 IdentityFile」にその絶対パスが記載されている。

vagrant ssh-config

秘密鍵の所在を確認した後、以下を実行する。

  1. 秘密鍵bashの~/.ssh配下に格納(多分ここじゃなくても大丈夫)。
  2. ファイル名を「id_rsa」に変更。

以下を実行すれば、パスワード認証なしでログインできる。

ssh root@127.0.0.1 -p XXXX

1を実施しただけではログインできなかったのだが、秘密鍵のファイル名は「id_rsa」じゃないとダメなんだろうか?

※追記

秘密鍵の指定って方法もあるのか。

www.ellinikonblue.com

Fireflyの設定変更

SSHログインさえできれば、あとは新規のログインユーザを作るもよし、そのまま検証するもよし。