応用情報技術者試験を受けたので記録しておく
これは何
2017年10月にIPAの応用情報技術者試験を受けました。12月合格発表で、結果が出た(合格した)ので、考えたことを記録しておく。
結果は?
点数は午前75、午後68ですれすれというほどでもないけどなんとも言えないところ。とはいえ、資格試験はボーダを超えるのが重要なので目標通りではあるのでOK。
応用情報って何
IPAが言ってる7段階のレベルの3に当たるもの。そろそろきちんとエンジニアとしてやっていくかな〜と考えているような人が受けるレベル。 午前試験と午後試験で分かれている。午前試験の開始が(特に私の所属する企業の)エンジニアの起床時間と比べて早いのが特徴的。 詳しいところ気になる方はググる感じでよろしくお願いします。
なぜ受けたか
- 大学が化学系で、情報系出ていないのでコンプレックスがある
- 受かると会社で一時金が出る
- 幅広い知識も業界内の専門外の人と話す時に重要と思った
- 経産省の調査で、諸外国含めたIT人材のレベルとお給金、的な資料を読んだ。だいたい自分のレベルとお給料の市場相場が一致しているのだなと気がついて、知識ベースアップのために受けてみることにした。(また、米国水準だと同じレベルだとお給金もうちょっと良さそうなので英語もぼちぼちやる) 参考資料: http://www.meti.go.jp/policy/it_policy/jinzai/27FY_report.html http://www.meti.go.jp/policy/it_policy/jinzai/27FY/ITjinzai_global.pdf
対策は?
前提知識(試験前のレベル)
午前試験
過去問見てみると業務で見たような単語が多い。過去問道場で雑にやってみると午前試験が無勉強で4割くらい取れる感じだった。最初のテキスト半分くらい読み終わった終わった段階で午前試験の過去問5割くらいだった。
午後試験
午後試験は10分野のうち4分野選択するのだが、私はセキュリティ、アーキテクチャ、ネットワークが無勉強で5〜10割くらいでばらつきあるが平均で合格点取れそうだが、あと1分野はどれも5割切りそうなのでどれとるか迷うレベル。
勉強時間は
多分30時間くらい。移動時間にやっていたのが多いので測定不能だがだいたいこれくらいだろう。平日の移動時間に10分くらいの細切れ学習時間の積み重ねと、土日のどちらかの1〜2時間くらいをカフェでのんびり参考書読む感じだった。 おそらく午前試験に20時間くらい。午後試験に10時間いかないくらい。
学習内容
午前試験
- 参考書を読む「キタミ式イラストIT塾 応用情報技術者 平成29年度」。この参考書はわかりやすくてよかった。他の参考書も買ったが、なぜそうなるのかとか書いておらず「公式」とか書かれていたのでゴミ箱に捨てた(比喩)。まずは本の7割くらい苦手分野を中心にざっくり読んだ。
- 過去問道場というサイトで電車内でちまちま過去問やる。過去問題解きつつ、わからなかったら参考書やググる。気になったものがあったら好奇心のままに調べる(ただし移動時間10分くらいの長さだけ。基本深くは潜らない)。
午後試験
だいたい1週間前(本格的には前々日)から午後試験対策をした。参考書は2週間前くらいに中古の安いやつ買った。「2014 応用情報技術者午後問題の重点対策 (午後問題対策シリーズ)」。この本も解説が詳しくてなかなかよかった。正直あんまり読んでないけど。版は古いがどうせ資格試験なんて大して内容変わらないだろうと思っての安いやつ。試験では新しい話題も出てきていたが、正直ベースがあればやはり解けるので新しいのにこだわらなくてもいいなと思った。業界内にいる人は普段から最新技術もなんとなく話を聞いているだろうし。 セキュリティ、ネットワーク、アーキテクチャは傾向だけさらっと見て、あと一分野どうするか決めるためにいろいろ解いてみた。
どれにする? 午後試験の問題は当日選べる。一夜漬けするならどれだ。
- マネージメント: 雰囲気で半分取れるが安定しない。博打なので無し。
- 情報システム開発: 過去問見る感じだといろんなフロー的なのとか出てくる。雰囲気でとけるが、しっくりこないのでとりあえず無し。他に選択肢がなければやる。
- アルゴリズム: 一つの大問に平均20〜30分が標準だが、問題によって40分くらい時間をかければ7割取れそう。できるようになれば硬いが、一夜漬けは無理そう。他の大問が早く終わって当日楽そうだったら(時間をかければ解けそうだったら)選ぶ
- データベース: 正規化とか設計の方はなんか本読んだことあるのでわかるが、普段ゴリゴリにSQL書いていないので副問い合わせとかなんか空欄にされるとなんかよくわからん。1週間ちゃんと対策すれば7割硬そうだがとりあえず無し
当日ぱっと見、情報システム開発の分野がテストケースの話で点数そこそこ取れそうだったので選択。なんとかなった。
辛かったこと
- これが一番難しいとされている。会場が家に近かったのでなんとかなった。
- 会場が寒い。雨の日だったこともあり午前試験で凍えてしまった。次の日から風邪引いた。ちゃんと厚着していくこと。
やってよかったか?
- 幅広いなんとなくの知識はついた。情報卒コンプレックスは多少解放されたが、次はさらに高度試験受けないと。完全解消にはやはり情報系大学院いくのが良いか。
- 正直午後試験はもうちょっと時間かけてやった方が身になった。知っている知識でごり押しした。
- BNF記法とか身近だけどあんまり意識していないものに触れられたのでよかった。
- 一番よかったことは、勉強習慣がついたこと。受験時代にやったようなことを思い出したので最近プライベートでもいろいろ自発的に学ぶようになった。
ansible vmware_guest_find モジュールを用いたVM存在確認と後続タスクの制御
これは何
ansibleによるVMwareのVMインスタンス管理の話。 VMインスタンスをコマンド一つで作成して初期設定ができるようにAnsibleで管理している。すでに存在するVMについては、うっかりRebootしたりNW Restartなどが走らないように存在チェックをしてそれらのタスクをスキップしたい。
vmware_guest シリーズの module について
- vmware_guest module
- VMを作るためのモジュール。ansible version 2.2 より使用可能。
- vmware_guest_find module
- vmware_guest_facts module
コードとハマリどころ
コード
# vmware_guest_findはすでにVMがいれば戻り値としてvm_folder.foldersにVMがいるディレクトリが入る(ここで、vm_folderはregisterで定義した変数)。居ない場合もしくは認証がうまく行かなかったなどの場合にはエラーになり、vm_folder.msgにその原因が書かれる。 # 後続のタスクは、VMがまだ居ない場合にのみ実行したい。 - name: check vm exists on vsphere vmware_guest_find: hostname: VMホスト名 username: ユーザ名 password: パスワード name: VMインスタンス名 datacenter: データセンタ register: vm_folder ignore_errors: yes # とりあえず ignore_errorsにしたけどfailed_whenで制御した方が綺麗だったかも。そのうちなおすかも。 - name: create and setting vm block: - name: create vm # ここら辺の中身は今回は略 include: create_vm.yml tags: create_vm - name: setting vm include: setting_vm.yml tags: setting_vm when: (not ("folders" in vm_folder)) and (vm_folder.msg | regex_search("Unable to find folders for VM"))
解説
vmware_guest_find module の戻り値。 Debugで見てみる。
- name: debug debug: msg: "{{ vm_folder }}"
VMがいるとき
"msg": { "changed": false, "failed": false, "folders": [ # これが帰ってくるのが特徴的 "/vm/hoge/development" ] } }
VMがいないとき
TASK [../ex_roles/vsphere_vmmaker : debug] ****************************************************** ok: [test-vmmaker] => { "msg": { "changed": false, "failed": true, "msg": "Unable to find folders for VM test-vmmaker" } # msgが帰ってくる。他の原因でmodule実行が落ちると他のmsgが帰ってくるのでそれを利用する。 }
- find と言う名前がついているので戻り値にBooleanが帰ってくるかと思ったらVM Folderが帰ってくるのだった
- ない時にはFalseが帰ってくるかと思ったらErrorになってしまうのだった
- 単に「find module実行が落ちたらVM設定する」にしてしまうと、なんらかの拍子にmoduleが落ちると意図せずcreate vm, setting vmが走ってしまって嫌だったので、それを念入りに回避するためにmsgを見ている
- もっと綺麗にかければよかったけど安全策をとった形
- find moduleはまだ安定していないので後方互換を取らないかもしれない、と言う注意文言があったのでmsgは変わるかもしれない(This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface. と書かれていた)
- msgがマッチしている時にだけ設定が走るので、msg文言が変わっても実行しないという安全側に倒れるので良い
コメント
インフラエンジニアがバックエンド書けるようになるために paiza と progate を使っている感想
これは何
バックエンド開発ができるようになるためにお家でPaizaやProgateを使ってPHPやRailsをお勉強している話。
目次
背景
私はメインの専門領域はWebインフラエンジニア(サーバエンジニア)なわけですが、そろそろアプリケーションコードもそこそこ書けるレベルじゃ無いと仕事がしづらいなと思ってきた。 だいたいコードの関連箇所の概要教えてもらったらコードを読み書きできるけども、自分一人で完全に問題箇所特定して修正してチューニングする、みたいなことがちょっとしにくい気がする(感覚的なもので、まだ何が知識として足りないか分かってないのでふわっとしている)
どう学ぶか?
会社で
一番いいのは会社で仕事としてアプリケーションコードを書くのが良い。とはいえ、私のメインで関わっているシステムはレガシーすぎるので「綺麗なコード」とか「良いアーキテクチャ」というのを学ぶのがなかなか難しい。本とか読めばある程度分かるのだろうが、ベースである程度読み書きして体に染み込んで無いと辛いところはある。
インフラ領域においてはやはりレガシーなところに放り込まれたが、3年という潤沢な時間をかけて試行錯誤しながら(なんとか動くくそコードを量産しながら)なんとか良い状態とは何かというのがなんとなく分かったつもりである。同じようにアプリケーションについて試行錯誤し続けるのも無駄な気がした。
自分で
となると、まずは独自で学習するしかない。ある程度分かってきたらそこそこ新しいシステムでアプリケーションコードを書かせてもらうように交渉するのが良さそう。 というわけで教材を探すわけである。とは言っても能動的に探したというよりも、問題意識を持っていたらTwitterで流れてきたのが目についてそれに飛びついた形。 さて、前置きが長くなったがPaizaとProgateについて。
Paiza
主観的な内容
競技プログラミングを学ぶためっぽい感じの内容だった。お題が出されてそれを実装する。主に実装速度(と高レベルになると実行速度)が見られる感じ。 実装速度を求められるのは新鮮で、就職活動をするときに自分の実力を知るためにFizzBuzzを時間計って頑張って書いたのを思い出した(10分以内にかけないくそプログラマもいる、と書かれている記事を読んだ後にやって7分くらいでできたので安堵したのを覚えている)。
選んだ言語
仕事でPHP関係が多いので、まずは最低限PHPコード読むのに苦労しない程度学ぼうと思ってPHPを選ぶ。
内容とレベル感
ざっくりやってみて、Bレベルまでは解けるのは分かった。このレベルだと、想定回答時間内に終わらないことも多いが、最終的になんとか回答できる感じ。Cレベルは普通にふわっと書いて終わるレベル。
Bで苦労するものがまあまああるので、Aは無理そう。
しばらく頑張ればBがスイスイ解けるようになるだろうと思ったが、今そうなりたいかと言われるとちょっと違うと思ったのでここで終わり。
自分とマッチしているか
ところで、Paizaは求人と紐付いているだが、きている求人があわなさそうなのが多いのでちょっとないかなという感じ。提案されるお給料にコーダーとしてのお値段を実感した。コードだけ書きたいわけでもなし、ここを極めるのは自分の進む違う感じがして一旦終わり。
Progate
主観的内容
Railsの教材を選んだ。そのせいか、コードを書くというより、アプリケーションを実際に作ってみるというのに重きを置いている感じ。ちょうど何か自分で全部作りたいなと思っていた時期だったので、マッチした。他のRubyの教材とかは雰囲気違うかも。
内容とレベル感
内容としては、「一気に全てを学びましょう」ではなくて、RailsだったらRailsの機能に焦点を当てているところが特徴的。当然、見た目それっぽいアプリケーションを作るためにはHTMLやCSSの知識も欠かせないわけだが、そこらへんは「ここにもう書いてあるのでコピペして該当箇所に貼ってね」という感じで、本当に基礎のところを知っていればスムーズに学びを進められる。綺麗なWebサイトつくるために後でそのコースも取ろうかな、と思わせる作り方なのがよかった。 今の所レベル26までやって、微妙に完全脳死ではできない感じでちょうど良い。
自分とマッチしているか
今の所結構良さそう。Railsはアプリケーションを高速で作るのに適していると聞くし、後で自分のプロダクト作るときに使えそう。裏の細かい技術的なことはインフラやってる経験から後からまあまあ調べられると思うし「だいたいこんなんで作れるだろう」というレベルまでいければ御の字。しばらく頑張ってみたい。
おまけ
N予備校
ちょっとだけやってみた。環境構築からしっかり学ばせるというコンセプトが強い。そこらへんは個人的には間に合っているので別にこれじゃなくていいかなというところ。本当のエンジニア初心者には結構良いかもしれない。関係ないが、世界史とかの講義を聞いていると「なるほどそういうことだったのか」という学びが大きいので、そういう一般常識的なものを学ぶのにむしろ使いやすそう。しかし講義は1時間とか長いのでもうちょっと細切れの方が楽だなあと思いつつ、ちゃんと流れで理解するためにはそれくらいのまとまりは必要だろうなどと思ったりする。
まとめ
昔は本使ってRails触ってみて続かなかった。Webサービス使うとうまく進捗や理解を管理してくれるので楽で楽しくやれる。微妙にお金はかかるけど専門書買うのより安かったりして最近麻痺してお金をいろいろ突っ込んでいる。
DNS切り替えを伴う環境移行のハマりどころと気をつけポイント
これは何
大きくサーバ群をリプレイスする時に考えるべきこと、詰まりどころをまとめておきたい。
目次
事前リソース見積もりについて
データ取得と方針
- 継続的にデータを取得しておく
- ピーク時平均値とスパイクするポイントが重要
- 負荷について
- 新環境は負荷をかけても耐えられるか。まずは旧環境と同様の負荷
- 今後の伸びを考慮した負荷
特に気にすべき負荷
ストレージ
- ディスクサイズ
- 負荷とは少し違うかも
- 今後の伸びを考慮した割当を行う。オンライン後から追加できるならある程度攻めても良い。補足:気軽に増やしたり出来ない物理サーバで5年でリプレイスするなら、5年後に70%になる程度にするとよいかもしれない
- IOPS ランダムアクセスに対する指標である。ブロックサイズが大きいものについてはIOPSが思ったより出ないこともある。その場合はスループットが重要
ネットワーク
- 新旧環境をまたぐトラフィックが発生する場合には特に注意が必要
- レイテンシ
- サービスでどの程度まで許容できるのか
- DBなのかcacheなのかでも違う
- トラフィック量
- LB、ルータ、スイッチ、ケーブルのキャパ
- 特に環境間のルータがボトルネックになるし、影響範囲も大きい
疎通問題について
- 同じIPセグメントなら問題は起こりにくい
- 違うセグメントに新サーバを立てるなら既存サーバから/に疎通ができるか
- L7レイヤまで確認するのが望ましい
- 必要に応じてルーティング設定をいれる
- 細かく /24に対してのroutingなどを入れていっても良いが、セキュリティ的な問題がない or リスクが飲めるなら /8 でいれるのもあり
LB・FWの設定について
- Global IPは割り当てられているか
- LB設定はすべてのドメインとパスに対して入っているか
- SSL証明書は設定されているか
- 鍵と証明書は行方不明になりがち
- 鍵の置き場(秘匿情報置き場)をあらかじめ決めておくと良い
- IP直うちでアクセスした時にどういう動きをさせるのか決めておく
- 503を返していいのか、何からのデフォルトサーバに到達させて200にするか、など
- 社内外からアクセスできるか
- 特に社内だけ空いていて、社外からアクセスできないということがないか?
- 必要に応じてACL設定を行う、もしくは抜いておく
DNS設定切り替えについて
ansible のダウンロード処理のリトライ(と既存コードの書き換えスクリプト)
これは何
playbook の自動テストで各種パッケージダウンロードの処理がたまに落ちていた。コードの問題ではないところで落ちてjenkinsが赤くなると嫌なので出来るだけ通るようにしたい。 リトライ処理をいれて問題の緩和を図りたい。 微妙に詰まったのでメモを残しておく。
参考文献
- get_url のreturn valuesについて;http://docs.ansible.com/ansible/latest/get_url_module.html#return-values
- untilのところ: http://docs.ansible.com/ansible/latest/playbooks_loops.html#do-until-loops
- result|succeededのところ: http://docs.ansible.com/ansible/latest/playbooks_conditionals.html#the-when-statement
コード解説
- name: download nginx source become: no get_url: url: "http://nginx.org/download/nginx-{{ NGINX_VERSION }}.tar.gz" dest: "/usr/local/src" register: download_result until: download_result|succeeded retries: 3 delay: 5
until, reties はセットで書く必要がある。untilの記述がなければretiesは1になる。 untilでの判定をするためにregisterで変数にタスク実行結果を入れておく。
おまけ
既存コードの書き換えのためのスクリプト
沢山の場所を書き換えないといけないのでperlスクリプトを使った。
grep -r "get_url:" | awk -F':' '{print $1}' | sort | uniq | xargs perl -i -0pe 's/(get_url:(.*\n)+?)^\s*$/\1 register: download_result\n until: download_result|succeeded\n retries: 3\n delay: 5\n/m'
以下スクリプト解説のようなメモ書きのような。
基本的にyamlのブロックごとに改行を挟んでいるので、それを用いる。
オプション修飾子mは対象文字列が複数行である場合に使う。
以下のような構造のyamlになっていた場合に、^\s*$
で空行までのマッチになる。
ここで(.*\n)+?
に?をつけているのは最短一致のためで、これをつけないと最長一致になってしまって空行1までではなくて、いけるところまでいったところ(この場合は空行2)までマッチするので注意が必要。
- name: download nginx source become: no get_url: url: "http://nginx.org/download/nginx-{{ NGINX_VERSION }}.tar.gz" dest: "/usr/local/src" (空行1) - name: hoge piyo: fuga (空行2) - name: hoge piyo: fuga
便利ツール紹介
ところで、正規表現を最初からコマンドラインで書くのもありなのだけど、あまりにも辛いのでGUIツールを使うのがよい。以下のサイトが最高なのでみんな使うべき。 https://regex101.com/
社内galaxyを作ろう
これは何
自分でansible galaxy を作る。特に今回は公開のものではなくて、社内に限る共通roleを作る話。 実際に作ったroleは社内事情や秘匿情報を含むのでここには書きません。
背景
社内クラウドのリソースを管理するplaybookをある人が作った。その後それをコピーして他のサービスで同じコードを使った(以下繰り返し)。 何かミドルウェア仕様が変更になったり、設定を変えたい場合にすべてのサービスでメンテナンスコストが発生する。 この状態は最低だと思ったので、社内galaxyを作り共通roleにしようと考えた。 その時に考えたこと、ハマったことをここに記録しておきたい。
参考
- http://docs.ansible.com/ansible/latest/galaxy.html
- その他いろいろgalaxyのレポジトリ
作り方
- meta/main.yml を配置する
- 内容は
ansible-galaxy init hoge
で適当なものを作ってコピーしてくるのが楽
- 内容は
- 使う
- 上のmetaファイルだけ置いてしまえばもうansible-galaxy installで読み込める
ansible-galaxy install git+http://github.fuga.co.jp/dw-ansible/piyo.git --roles-path ./ex_roles/
- 整理する
- あくまでgalaxyはroleを共有するという感じなので、普通ansibleレポジトリにはinventoryやplaybookファイルが含まれていると思うが、それらを削除する
- defaults/* ファイルへデフォルト設定を配置する
defaults/ について
- どのようなサービスでも共通の設定はmain.ymlにおいておくと良い
- 必ず変えて使って欲しいという変数はあえてデフォルトを配置せず実行時にエラーで落ちるようにしたほうが安全かなと思った
- main.ymlは読み込まれるが他は特に指定しなければば読み込まれない。変えて欲しい値だけどテンプレートは欲しいよねというような値はtemplate-*.ymlみたいなのをおいて読み込み先のplaybookでコピーして書き換えてもらうのがよさそう
その他
- 社内共通galaxyは、作るのはそこまで難しくないことがわかった
- むしろ広報や運用が難しい。使ってもらわなければroleは育っていかないし、破壊的変更をすると困るユーザがいるはずなので合意を取って前にすすめていくのは大変。後方互換を保ったまま育てていくのもカオスになりがちだし、これからそこの悩みが出てきそう
- とはいえ、作ればみんな喜ぶので積極的に共通パーツを作って展開していきたい
netscaler LBにおいてサーバを使わずにリダイレクトする
これは何
netscaler LBにおいて特定FQDNへのアクセスをパスそのままで他のFQDNにリダイレクトする方法についてまとめる。 この資料は NetScaler version 11.0 で実験した動きを元に書いています。
目次
参考資料
https://support.citrix.com/article/CTX120664 大体これを読めばできるが以下の問題があった(この資料を作るモティベーション)
- LoadBalancing Virtual Server の設定のところがServiceと書いてあり誤植と思われる
- 設定箇所の階層が書いておらず多少読みづらい
- LoadBalancing Virtual ServerにGlobal IPを設定するパターンしか書かれていない
手順
System設定でresponderの有効化
NetScaler -> System -> Settings -> Configure Acvanced Features
responder にチェックを入れる。
Responder Actionの設定をする
- Addする(既存のActionを選択してAddするとそれをテンプレートとして使うことになる。最初から作るなら選択を外してAddする)
- TypeはRedirectを選択
- Expression
例1) http->httpsにリダイレクトするなら、スキーマのところだけhttpsと書いて後は同じ
"https://" + HTTP.REQ.HOSTNAME.HTTP_URL_SAFE + HTTP.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE
例2) 特定の別のドメインにリダイレクトする
"http://piyo.jp" + HTTP.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE
補足: L7で http://hoge.jp/fuga などで入ってきたLoadBalancing Virtual Server経由でこのactionで http://piyo.jp/fuga に飛ばすイメージ
* Response Status Code を設定する デフォルト 302
Responder Policy の設定をする
- さっきのActionを設定する
- Undefined-Result ActionをRESETにする
- Expressionには HTTP.REQ.IS_VALID を設定(frequently Userd Expressionから選択すると良い)
- 要するにこのpolicyでは特に何もせずに(validかチェックだけして)actionへ流すという意味か
monitor 設定をする
localhost に pingをうつmonitor設定を作る
- name: localhost_ping
- Type: PING
- destination ip: 127.0.0.1
service を作る
上で作成したmonitorを使って常にserviceがUP状態になるようにする。あくまでダミーで、LoadBalancing Virtual Serverが常にUP状態になるようにするためのものの模様
- 上記serverを紐付ける
- ProtocolとPortはHTTPと80とでも適当に設定しておく
- 作成後、Monitoring設定で先程作成したmonitorを設定し、UP状態になることを確認する
LoadBalancing Virtual Serverを作る
- IP Address: WebサイトのIPアドレスもしくはPrivate IP
- Global IPで直接受ける場合にはここに設定
- Content Switching Virtual Server通すならここはPrivate IPを指定する
- 作成後Responder Policyを設定
Content Switching Virtual Server 設定
上記でLoadBalancing Virtual ServerにPrivate IPを設定した場合にはContent Switching Virtual Serverのpolicyに紐付ける この手順はredirector特有というよりもContent Switching Virtual ServerからLoadBalancing Virtual Serverに流す手順と同じなので省略する