フツーって言うなぁ!

フツーなサラリーマンのフツーな嘆き.

Web APIのログ設計についての私見

かなり放置してしまいましたが,久しぶりに気分が乗ったのでブログを書いてみています.

最近は仕事でSpring Frameworkを使って何度かWeb APIを開発しているのですが,その度に毎回同じようなことを悩んでいる気がするので,次に開発する自分に向けて,ちょこちょここちらにまとめておこうと思います.

結構私見が混ざりそうなのでこちらのブログで.

今回はログについてです.

注意事項

  • 対象は,DBや他のAPIと通信して結果を返すタイプの一般的なRESTful APIを想定しています.
  • 業務領域はちょっとカッチリ目のWeb系です.
  • 特定のWebフレームワークには依存しないように書いたつもりですが,見返してみると若干Spring Frameworkに寄ってるような気もします...

ログ設計の観点

そもそもですが,Web APIのログってどんなものがあればいいのでしょうか?

仕様面の観点としては,

  1. 障害発生時にできるだけ早く運用者に通知されるようになっているか?また,ログから障害の原因を追跡しやすいか?
  2. APIクライアントからの問い合わせなど,日常運用に際して使いやすいか?もう少し具体的に言うと,そもそもログの中から問い合わせの対象となるリクエストを見つけやすいか?また,ログの内容から問い合わせを解決するための手がかりをつかみやすいか?
  3. 業務量(QPS)やリクエストの実行時間を把握しやすいか?
  4. 開発時に起こった問題の原因を追いやすいか?(要するにデバッグログ)
  5. その他,開発者/運用者/ログ分析者が知っているとよい情報を適切なタイミングで表示しているか?

があるかなぁと思っています.

要するに,使いやすいログを設計しましょう,ということです.

また,性能面の観点としては,

  1. ログの出力がAPIの性能に大きく影響しないか?
  2. ログによってシステムの他の構成要素に影響がないか?

といったところも重要です.

何も考えずたくさん出してしまうとログ追跡も難しくなりますし,ログ出力そのものがAPIの負荷の原因になったり,ログを吐き出しすぎてディスク溢れを起こしてしまったりするケースもあります.

これらの観点を鑑みて,私は以下のようにログを設計しています.

ログ設計

ログ分割と各ログの役割

以下の4つのログをファイルの形でAPIサーバに配置しています. その後,fluentd等のログ集約ツールで適宜集約サーバに送信するようにしています.

(以下,ログレベルはSLF4Jのものを基準としています)

SLF4J

request.log

APIが受けたリクエストを記録するログ.

HTTPのリクエストパス,クエリ文字列,リクエストボディ,リクエストヘッダ(,クッキー),リクエスト元のIPアドレスを記録します.

特に,何らかのバグによって途中でレスポンスが返らないまま処理が終了してしまう場合も考えて,できるだけ早いタイミングでログを記録することが重要です.

ログレベルはINFO.

response.log

APIが返したレスポンスの内容と,リクエストの処理にかかった時間(経過時間)を記録するログ.

HTTPのステータスコード,レスポンスボディ,レスポンスヘッダ,経過時間を記録します. アクセス量の調査については,基本的にこのログを利用します.

加えて,

  • APIのID(呼ばれたAPIを一意に識別するID)
  • ユーザのID(あれば)
  • ユーザが認証済みかどうか(認証済みユーザにのみコンテンツを開示する場合など)
  • APIクライアントのID(あれば)

あたりを別に記録しておくと,ログ検索の際の利便性が上がると思います.

ログレベルはINFO.

application.log

APIの内部ロジックにて,開発/運用に必要な情報を記録するログ.

いわゆるアプリログ.

ログレベル 観点
TRACE 基本的に使用しない.開発時に本当に必要になったときのみ.
DEBUG デバッグの際に必要な情報を記録する.DEBUGレベルのログは本番環境で出力することを想定しない.「開発/デバッグ時にはいつも必要になるが本番には出したくないログ」のみを残し,開発中にだけ必要だったものなどは本番投入前に消しておくようにするとよい.例えば,DBに接続する際の接続情報や,APIロジック内での処理件数,経過時間など.
INFO 本番運用に際して有用な情報を記録する.INFOレベル以上のログはすべて,本番環境で出力することを想定する.不要な情報はできるだけ削ぎ落とし,本当に必要な情報のみを出力するようにする.特に,毎リクエストごとに出力されるログについては吟味し,request.log/response.logに入れられないかを検討する.例えば,バックグラウンド処理が起動/停止したことを示す情報や,APIの設定項目が更新された際の通知など.
WARN 「即時の対応が必要ではないが,運用者にすぐに通知されるべき警告」を記録する.自動電話の対象とはしないが,メールやSlackなどのメッセージングツールなどで運用者がすぐに把握できるようにはしておく.例えば,APIが想定しない入力が受け付けた場合や,(マッシュアップAPI等で)一部の外部APIの呼び出しがエラーを返した(がAPI全体には大きな影響がない)場合など.
ERROR 「運用の継続を阻害しており,即時の対応が必要なエラー」を記録する*1.エラーの詳細(例外のスタックトレースなど)がわかるようにしておく.アラートの対象であり,自動電話等で夜間帯でも即時対応できるようにしておく.例えば,APIの業務ロジックが想定しない例外を送出した場合や,メモリやディスクの枯渇によってAPI自体の状態が不安定になった場合など.

stdout.log

フレームワークが吐き出すログの内容をリダイレクトして記録するログ.

多くのWebフレームワークでは,フレームワーク側で実行した内容のログを標準出力に出力する設定になっていると思うので,それを記録しておきます.

ログレベルは出力したログに依存します.

気をつけるべきところ

ファイルフォーマット

プレーンテキストで記録してもいいのですが,一度集約サーバに送ってしまうと目視で確認する機会がほぼなくなってしまうので,プログラムで処理しやすい形式が良いかと思います. 個人的にはJSON形式がおすすめです.

ちなみに,ロギングにLogbackを利用しているのであれば,logstash-logback-encoderを利用することで,いい感じ(Logstash形式)にフォーマットしてくれるので,ELKで扱いやすいです.

GitHub - logstash/logstash-logback-encoder: Logback encoder which creates JSON for use with Logstash

JSONを使う場合でも,例えば開発時には目視しやすい方が楽かと思うので,必要に応じてフォーマットを変更しやすいようにしておくとよいかと.

リクエストID

ログごとにファイルを分割すると問題になるのが,どのログがどのリクエストに紐付いているのかわからなくなる点です. 例えば,request.logから同じリクエストに紐づくresponse.logを探すことができなくなります. このため,各ログには,リクエストごとに(ほぼ)*2一意になるIDを付与するようにしています.

ちなみに,ZipkinやJaegerなど,OpenTracing APIに対応するトレーサーを利用しているのであれば,IDとしてTrace IDの値を使うとよいかと思います.

時刻

ログの中でいちばん大事なのは,そのログを取った時刻の情報だと思います. もちろん要件次第だと思いますが,普通のAPIであれば,精度はmsecぐらいあれば十分かと思います.

時刻のフォーマットについては,ISO 8601の基本形式か拡張形式のどちらかを使っておけばいいと思います.

ISO 8601 - Wikipedia

私はよくuuuu-MM-dd'T'HH:mm:ssSSSXXX (E.g., 2018-10-27T22:17:35.213+09:00)のフォーマットを使っています.

ログローテーション

サーバのディスク容量には限りがあるので,ログがディスクを圧迫しないようにすることは重要です. 多くのロギングライブラリには,日別や日時別でログファイルを分割して古いファイルを圧縮,削除するログローテーション機能があるので,それを使うとよいと思います.

忘れがちですが,ログが溢れないかどうか,開発時に負荷試験で調べておくことも重要です.

ある程度信頼性を犠牲にしていいなら,ファイルを介さず直接TCP等で集約サーバに送ってしまう,という手もあるかと思います*3

リクエスト元のIPアドレス

リクエスト元のIPアドレスについては,(他にAPIクライアントを識別するための情報があれば必須ではないものの,)どのAPIクライアントのどのサーバがAPIを呼び出しているかを把握していると障害対応が楽になるため,できれば取得しておきたい情報です.

様々な取得の方法がありますが,APIクライアントと取り決められるなら取り決めた方法で,特にそういうものがないなら,

  1. X-Forwarded-Forヘッダが存在する際は,その値を,(カンマとスペース1つ)で分割した際の最初の要素(ロードバランサやリバースプロキシを経由するなどしてIPアドレスの付け替えがあっても対応できるので*4) 2.X-Forwarded-Forヘッダが存在しない場合は,REMOTE_ADDR(前段の呼び出し元IPアドレス

を取得するとよいかと思います.

X-Forwarded-For - Wikipedia

参考記事

qiita.com

7.1. ロギング — TERASOLUNA Server Framework for Java (5.x) Development Guideline 5.4.1.RELEASE documentation

www31.atwiki.jp

*1:RESTful APIであれば,APIクライアントにはステータスコード5XXを返すことになる.その際,レスポンスにエラーの詳細を記載するとセキュリティ面で問題があるため,問題が発生している旨のみ記述して残りはマスクしておくとよい.

*2:もし衝突してもちょっと探すのが面倒になるぐらいなので,あまり一意であることにこだわりすぎなくてもよいかと.

*3:最近はこちらの方が主流なんでしょうか...

*4:厳密に言うと,ヘッダの値は改ざん可能なので信頼できる値ではないけれど.

昨年やったことと今年やりたいこと 2018

↓2017年版 lethe2211.hatenablog.com

去年やったこと

Rustハッカソン

あんまりここで書いたことはなかったけれど,就職してから1年に1度,GWあたりに有志で温泉ハッカソンをしている.
お題を決めて1晩でやる形式で,以前やったのはGoLangとかSwiftとか.

今年は湯河原のおんやど恵で行い,お題はRustだった.

www.onyadomegumi.co.jp

コンパイルが通せる程度のプログラマにはなりたい,という気持ちだった…

「達人プログラマー」でも言ってたし,1年に1度ぐらい新しい言語に触れるのもいいと思うけれど,役に立つモノが作れた記憶が無いので,今年もあるなら頑張りたい.

新装版 達人プログラマー 職人から名匠への道

新装版 達人プログラマー 職人から名匠への道

富士登山

とうとう登った.

登頂には吉田ルートを使った. もともと登山道がそこまで広くないのと,シーズンだったためか,登山道が非常に混雑していて,もはやアトラクションの待機列に並んでいるようだった.

8合目の山小屋で1泊した. 事前に「山小屋は寝るためだけの場所」と聞いていたので,あまり期待していなかったが,ご飯もちゃんと出たし,特に困ることはなかった. 夜中に起きて出発したが,星がめちゃくちゃキレイだった*1

9合目を過ぎたあたりから急に列の人が減って(高山病で脱落した?),日の出の時間が近づいてきたこともあり,誘導のおじさん達に急かされながら最後の数百メートルを登った. ココが一番キツかった.

山頂に着いたが,残念ながら天気が大荒れで,あまり日の出は見えなかった. 最初は山頂付近を1周することも考えていたが,キツそうなのですぐに下山した.

次登るのであれば,吉田ルート以外にしたい*2

上海&台湾旅行

11月,12月と,立て続けに上海,台湾に行った.

上海は,厳密に言うと旅行ではなく出張だったが,そんなに仕事をした記憶が無いので実質旅行だったと思う. 摩天楼がキレイだった. あと,上海ガニを初めて食べた.

台湾には家族旅行で行った. 台北市内や,アニメ映画の舞台になった九份など,北部を中心に回った. 家族にここ数年海外旅行に行った人が自分しかおらず,フォローに苦労した. 今度は一人で行きたい.

とりあえずNISA枠現物取引から始めてみた. 一応今のところプラスだけど,そもそも元金が多くないからそんなにでもない.

今年はもう少しつぎ込んで,少しづつ結果を積み重ねていきたい.

最近は仮想通貨(取引 & マイニング)が流行ってるけどどうなんだろう.

Data Science Online Course

gci.t.u-tokyo.ac.jp

去年の10月から今年の3月までの期間,社会人向けデータサイエンスのオンライン講義を受けることになっている.

最後まで終わった後にヒマができたら,こちらについても記事を書きたいと思ってはいる.

統計検定(2級)

lethe2211.hatenablog.com

機会があれば,準1級にも挑戦してみたい.

システムアーキテクト試験

lethe2211.hatenablog.com

今年やりたいこと

なんか全体的にふわっとしているので,もう少し具体的な目標にしたい気もする.

趣味プロダクト開発

学生時代以来,完全な趣味で作ったプロダクトがないので,転職面接用のデモ作品を兼ねて何か1つ作りたい.

あまりまとまった時間が取れなかったことと,作りたいものが明確にイメージできなかったことから,見せられるプロダクトを開発する機会がなかなかなかった.

今だとスマホアプリとかになるんだろうか,ノウハウないけれど…

技術のアウトプット

そろそろ,ここ数年学んだ技術をどこかにアウトプットしていきたいという気持ちがある.

できれば一度どこかの勉強会に登壇してプレゼンしたいけれど,そこまででなくても,ブログで流すようにしたい.

アウトプットを目標として学んでいけば,場当たり的な知識にとどまらず,もう少し体系的に勉強する癖がつくと思うので頑張りたい.

料理

「やっぱり,料理できる人はカッコイイよなー」ということを最近ひしひしと感じている.

今までも自炊はしてきたけど,そんなに頻度も多くないし,そもそも料理と呼べるか怪しいものが多かった*3

ハウツー本でも買って,週末のヒマな時間にでも少しずつ始めてみたい,煮物とかちょっと時間のかかりそうなやつも含めて.

お絵かき

最近iPad ProとApple Pencilを買ったので,ペンタブ代わりにしてちょっとお絵描きしてみたい.

年末にちょっとやってみて思ったが,最低限の絵が書けることはそれなりに必要だし,絵を書く過程で対象のモノの観察をすることは結構アタマを使うので面白いと思う.

自分に画才がないのは重々承知しているし,めちゃくちゃ上手くなろうと思っているわけでもないが,少しずつやっていきたいと思う.

Apple iPad Pro Appleペンシル/MK0C2J/A

Apple iPad Pro Appleペンシル/MK0C2J/A

抱負

「地に足を着けて実行する」を今年の目標にしたい.

自分ではいろいろと基本的なことを学んではきたつもりだが,まだまだ分野の一流の人達には到底及んでいない. スペシャリストになる人の特徴として,同じ分野を飽きずに突き詰められる能力というのはあると思う.

その時その時にやりたいことをやるだけでなく,少しまとまった時間(1ヶ月とか)を作って,大きな作業を着実に進める癖をつけたい. また,個々の作業をがむしゃらにやることも必要ではあるが,時にはまわりを見渡して方向性を確認するようにしたい.


去年感じましたが,こういうところで宣言しておくとモチベーション保ちやすいのでいいですね.

*1:写真に撮っておけばよかった

*2:山は他にも塔ノ岳とか赤城山とか登った

*3:「冷蔵庫にあるものを炒めただけ」を料理と呼べるか?

システムアーキテクト試験を受けてきた

前に情報処理技術者試験はもう飽きたとか言ってたような気もしますが,懲りずに受けてきましたので,毎度のように何やってたか簡単にまとめておきます.

概要

システムアーキテクト試験(SA試験)は,主にシステム開発の上流工程を担当するエンジニアに向けた試験で,簡単に言えば,要件定義,外部仕様設計あたりを主な出題範囲としている. 対象となるシステムは,情報システムと組込みシステムの2つがあり,その中から自分が得意な分野の設問を選択して解答できる作りになっている.

www.jitec.ipa.go.jp

出題傾向

試験は,

  • 午前1(全問必答.多肢選択式.50分.問題は全高度試験で共通)
  • 午前2(全問必答.多肢選択式.40分)
  • 午後1(4問中2問選択.記述式.90分)
  • 午後2(3問中1問選択.論述式.120分)

の4つ.
スペシャリスト試験とは違い,午後2試験が論述問題になっている.

出題形式はわりと明確で,かつ年度によるブレは大きくない印象.

午前2で基本的な知識を確認.

午後1では,与えられた現状仕様/システムを理解し,そこからシステムを設計したり改修したりする問題が多く出題される. 4問中3問が情報システム,残りの1問が組込みシステムについての設問.

午後2では,リード文を読んだ上で,自身の経験をもとにした論文を書く. 試験の最初に,関わった業務やシステムについての基本情報の欄を埋めてから,各設問について論述していく. 「設問ア」,「設問イ」,「設問ウ」の3つの設問があり,それぞれ,「800字以内」,「800字以上1,600字以内」,「600字以上1,200字以内」という字数制限がある. 3問中2問が情報システム,残りの1問が組込みシステムについての設問.

受験動機

正直に言って,スペシャリストを3つ取ってしまって情処に対するモチベーションはかなり下がっていたし,やろうと思えばいくらでもネタのでっち上げができそうな論述試験なんてやる意味あるのかという疑問は拭えなかったが,

  • 業務で上位設計者としての仕事を任されることが増え,一般的なアーキテクトができる(しなければならない)ことが知りたくなった
  • モチベーションが高かった頃になんとなく買った参考書が残っていた
  • 午前1免除がもったいなかった
  • 「エンジニアにも説明力が必要」というこちらのブログ記事の内容に大きく頷くことができた

dimeiza.hatenablog.com

*1

これらから,受験を決めた.

やったこと

2017年8月中旬

上記のように思い悩みながらも受験申し込み.

8月下旬〜9月上旬

少し時間が取れたので,午後試験を中心に勉強を始めた. 自身の業務領域と問題数を考えて,組込みシステムの問題を取ることは100%ないと思ったので,最初の段階で捨て,情報システムの問題にヤマを張ることにした.

使ったのは,先ほど挙げた参考書.

情報処理教科書 システムアーキテクト 2017年版

情報処理教科書 システムアーキテクト 2017年版

午後1については,1問やってみて多少の手応えを感じられたので,労力少なめで進めることに決めた. やはりスペシャリスト試験に比べると技術まわりの出題の難易度は低く,業務でもアーキテクトとして理不尽&&意味不明な仕様と闘っていることもあり,問題文の勘違いさえしなければ,さほど厳しくはならないだろうと感じた. 解く際には,問題文の重要そうな点には線を引くようにし,また,データの流れが複雑な場合についてはできるだけ図を書くように工夫した.

やはりキモになってくるのは午後2で,一度何も考えず問題を解いてみて,これは慣れが必要だと感じた.

まず,とにかく手書きがダルい. 普段はほとんどシャーペンを持たないので,腱鞘炎になりそうで文字を書くのがただただつらかった. また,手書きはPC入力と違ってBackSpaceやコピペが使えず,かつ,解答用紙はマス目のついたタイプのものなので,文章の構成ミスや誤字脱字に後から気づくと修正が事実上不可能になってしまうのもいただけない.

加えて,時間は120分と,字数を考慮すると非常に短く*2,時間配分もキッチリやらないと到底書き切ることができない.

結果,1問目は途中で解くのを諦め,おとなしく上述の参考書やWeb記事にしたがうことにした.

どうやら,この試験にはある種の必勝法があるらしく,合格体験記を見ると,大方の人がそれを実践していた.

0.設問アについては,毎年ほぼ変わらず「関わった業務とシステムについての概要」を問われるので,表現も含めて暗記しておく(ついでにある程度字数調整できるようにしておく).

1.試験開始後の30~35分程度で,その後の設問で書きたいことを,(字数制限を考慮した上で)箇条書きにしてまとめる.ここで,論旨展開(設問アで設問イへの伏線を張っておく,設問ウで書きたいことは設問イでは書かない,など)についても考慮しておく.

2.残りの時間でひたすら書く.ここで,箇条書きの部分はそのままそれをタイトルとして書き,その後に詳細を書いていくスタイルで進める(ここで筆が止まる場合は,1での論旨のまとめ方が不十分ということなので反省する).

といっても,やはり最初から手書きは厳しいので,まずはPCのテキストエディタに要点をまとめることとした.

現在はWeb企業で業務APIプラットフォームの内製開発,運用をしているが,現状運用している業務とシステムについて,その概要を書くというのは,自分にとって意外と新鮮な体験だった. ふわっとした理解だったものも,論理的な文章にしようと思うと,間を埋める努力をしなければならず,その度に運用ドキュメントを当たるなどした. これは非常にいい経験になったと思う.

ある程度まとまってきた段階で,同じ問題を時間を測って解いてみて,「この方法で行けそう」と確信した.

字数が数えられるタイプの紙が家になかったので,罫線の上にドットがついているタイプ*3のレポート用紙を買った. ホントは原稿用紙みたいなマス目になってるやつが欲しかったけど,これはこれで結構便利だった↓

9月中旬〜下旬

少し仕事が忙しくなってきたが,ペースを落としつつ午後2の対策を続けた.

難しいのは,30分程度で十分な字数を確保できる内容を考えるところと,箇条書きの部分をちゃんとスジの通った文章にするところ.

前者については,結局はプロジェクトを経験した数(≒引き出しの数)による部分が大きく,特に苦しんだが,それでも内容のでっち上げはできるだけ避けたかったので,関わったプロジェクトの内容を逐一思い出して書くようにした. それでもダメな部分については,実際には運用しかしていないシステムを開発した体で書くようにするなど,できるだけ具体性を損なわないようにした*4

後者については,ある程度問題演習をすることで慣れてきたと思う.

また,問題で問われていることを勘違いして2時間をムダにすることもあったので,問題文だけでなく,リード文もよく読むように心がけた. 特に,リード文における例示については,注意を払って読むようにした*5

加えて,問題を解いた後に,参考書の合格論文をざっと読んでみて,解答の方向性にズレがないかを常に確かめるようにした.

10月上旬〜中旬

このあたりから少しだけ午前対策を始めた. といっても,2年分過去問をやって,イケそうなのですぐにやめた.

基本的には午後試験の対策をしていた. 結局試験前までに解いたのは,午後1が3年分(6問),午後2が5年分(5問). これは今までの情処の試験対策の中では最も少ない.

当日

実際に解いた問題↓

IPA 独立行政法人 情報処理推進機構:問題冊子・配点割合・解答例・採点講評(2017、平成29年)

午前1

免除.

午前2

いつもの起床ゲー+暗記ゲー. 受けた記憶すら曖昧.

午後1

「ああマイナンバー出たかー.これ問題難しくしたらいろんなとこから怒られるんだろうなー」と思って問1,雰囲気で問3を選択.

問1はデータの流れが追えれば比較的簡単だったが,問3の人事関連の業務フローを理解するのは少し難しかった. パッケージソフトウェアのFit & Gap分析の問題はちょいちょい出るらしいので,来年以降受けるなら調べておいてもいいかもしれない.

午後2

「非機能要件」の定義に少し自信がなくなって問2を取ろうかと思ったが,問2の方がふわっとしてて出題意図を踏み外しそうなので問1を選択.

自分が問題用紙にメモした内容(をちょっとキレイにして出しちゃうと身バレしそうなところを改変したもの)を晒しておく.

設問ア:
アー1:要件定義に関わった対象業務の概要と情報システムの概要
 * 自身はWeb企業のシステムアーキテクト
 * XXXサービスに従事
 * XXXサービスとはうんぬん(を書く)
アー2:情報システムの概要
 * 自身が担当したのはYYYバッチシステム
 * YYYバッチシステムは,XXXサービスを運用するためのYYYシステムの一部
 * 自社他部署及び他社がクライアント
 * クライアントから連携されるデータ(1000万レコード/日程度)をもとに,システムのDBを更新
 * コスト面から,運用できるサーバ数には限りあり

設問イ:
イー1:検討した非機能要件
 * 効率性と運用性のトレードオフについて検討
イー2:検討した際の視点とプロセス
 (1)業務観点での検討における視点とそのプロセス
  * 利用部署へのヒアリングを行う
  * 業務要件:データの更新は更新データの連携日の翌日午前中まで(できればもっと早く)に行いたい.データ量は1000万レコード+バッファ
 (2)情報システム観点での検討における視点とそのプロセス
  * 現状のサーバを調査する
  * 簡単なストレステストを行う
  * バッチプログラムはシングルスレッドを想定(簡単な実装であり,運用性が高いから)
イー3:検討した結果
 * バッファ込み3000万レコードでストレステストしてみた -> 9hかかる!
 * 業務要件を考えると時間がかかりすぎ
 * バッチのマルチスレッド化を検討

設問ウ:
 * 意思決定者=YYYシステムの開発責任者
 * 現状のサーバ構成は変えられないことを意思決定者に確認
 * シングルスレッド版,マルチスレッド版のそれぞれについて,バッチのプロトタイプを作り,3000万レコードを読み込ませた時の速度を見てもらう
 * マルチスレッド化により運用性が下がることを示す

基本的に,上記のメモベースで箇条書きを行い,それぞれに内容を補足する形で実際の論文を書いた.

少しでも大量データを触る機会のあるエンジニアなら,最初はシンプルなコードでとりあえずプログラムを書いてみて,負荷試験でダメなら仕方なく手を入れる*6という開発経験をされた方は多いのではないだろうか. わりと自身の経験に基づいたものになったかなとは感じる.

設問イまではわりとうまく書けたが,設問ウでネタ切れを起こしてしまい,字数を必死に稼いで600字超ギリギリまで持っていった. やはり,文章構成を考える段階で字数制限より少し多めにネタを考えておいた方がいいと思う.

結果

f:id:lethe2211:20171223015720p:plain 合格でした.

感想

全体的に暗記する項目が少なかったので,比較的コンパクトな勉強で合格点まで持っていくことができた. どちらかと言うと,特定の分野について勉強したことを問うというよりは,地頭の良さと日頃の文章力を見る試験という印象.

個人的には,ただただシステムの設計について記述するだけでなく,数多くいるステークホルダへそれをどのように説明するかという観点が問題に組み込まれているのが面白いと思った. 実際に上位設計者としてやっていく以上,ただシステムを作ればいいのではなく,システムの対象領域となる業務を理解し,かつ,作ったものの仕様や設計意図を(相手の背景知識に合わせて)説明できるようになることが重要なのだと感じた*7

でもまあやっぱり,「こんな妄想たっぷりの論述で本当にシステムアーキテクトととしての能力がわかるんだろうか」という疑問は最後まで解決されなかったのと,イマドキの試験で数千字の文章を手書きで書かせるのはどうなのという感じはした.


たまには資格試験以外の技術記事も書きたいのでちょっとがんばります…

*1:こちらの記事,試験対策記事としても非常にお世話になった.感謝.

*2:2,500字って大学の期末レポートより少し短いぐらいだし.

*3:伝われ.

*4:たぶんシステムへの理解を深めることも試験の重要な目的だと思うので許して.

*5:基本的に例示に沿ってそのまま書けば得点的には問題ない気もするが,あまりにコピペをしてしまうとそれはそれでなんかダメな気がする.試験講評でも毎年怒られてるし.

*6:だいたい後からいじった部分がぐちゃぐちゃになって保守できない原因になってくるのだが.

*7:流暢な文章にできることと,同じ内容を口頭で伝えられることは(特にコミュ障にとっては)一致しないが,相手に説明すべき観点が理解できるようになるだけでも,まあ一歩前進という感じはする.

情報処理安全確保支援士の集合研修を受けてきた

久しぶりの更新です.

情報処理安全確保支援士の資格を取って初めての集合研修を受講してきたので,ちょこっとメモしておきます.

lethe2211.hatenablog.com

情報処理安全確保支援士では,資格維持に年1回のオンライン講習と3年に1回の集合講習が義務付けられています.
今回は,この中で集合講習を受講してきました.

時間は9:45〜17:30の約8時間(休憩込み)で,内容としては,大きく,

  • 理解度確認テスト
  • 30分程度の講義(座学).
  • 40分程度,5人1組のグループに分かれてのグループワークx3.

でした.

詳細については(口止めがあるので)書きませんが,講義では,情報セキュリティインシデント対応と,支援士としての倫理について総論を学び,グループワークでは,それを実践する形で,グループ内で議論を行い発表しました.

特徴的だったのは,講習の大部分がグループワークになっている点.

架空の企業で起こったインシデントについて対応や予防策を検討する,支援士としての倫理について考えるという2つのテーマがあったのですが,どちらも設問の前提がわざと曖昧にしてあり,教科書的な回答だけでなく,メンバーの知識と経験に基づいた意見を求められるので,なかなかアタマを使いました.
また,倫理の問題では,顧客からの職業倫理上問題のある依頼をどう扱うかなど,実際に直面するであろう問題に近いものもありました.

支援士試験自体の合格率と資格の維持費からか,グループの方は皆見た目30代後半〜40代以上で,かつ企業内でもソコソコの役職の方が多かったです.*1
議論をしていても,技術まわりの話よりはマネジメントや社内規定の話になることが多く,自分との視点の違いを感じました.
これは受講してみてよかった点だと思う反面,全体を通してもう少しセキュリティ関連技術の話ができると楽しかったかな,とも感じました.

この記事を書くことで受講料8万円(自腹)を供養…できるといいな.

*1:正直僕は完全に浮いてました

統計検定2級を受けてきた

情報処理技術者試験に若干飽きてきたので(?)受けてきました.

www.toukei-kentei.jp

概要

「大学基礎科目レベルの統計学の知識の習得度と活用のための理解度を問うために実施される検定」だそうです.

試験範囲は,多くの大学で1,2年次に教養科目として開講されている「確率論」と「統計学」の内容におおかた沿ったものとなっています*1

また,2級と3級については,PBT(マークセンス方式の筆答試験.6月と11月の年2回開催)に加え,CBT(コンピュータに解答を入力するタイプの試験.随時開催)も用意されているので,わりと気軽な気持ちで受けられるかと思います.

出題傾向

上で述べたように,大学教養レベルの統計が範囲です.

特に,

  • データの分析,可視化(度数分布表,ヒストグラム,箱ひげ図等)
  • 高校レベルの確率計算,ベイズの定理
  • 標本調査の方法,実験計画
  • 確率変数,確率分布の性質と平均,分散等の計算
  • 統計的推定(点推定,区間推定)
  • 統計的検定(z検定,t検定,x2検定等)
  • 回帰分析

あたりは押さえておくと良いでしょう.

経緯

そもそも大学の専門はコンピュータサイエンスだったので,統計学は教養でちらっと学んだ程度でした*2

数ヶ月ほど前に統計学に興味を持ち始めたのですが,Web上に落ちている記事をいくつか読んだだけでは体系的に知識を得るのが難しいと考えていたところ,ある勉強会で統計検定を知りました.

巷には,「なんとなく」統計・機械学習の技術が使えるようになるライブラリやフレームワーク等がありますが,やはり理論的な背景もある程度知っておきたいと思い,そのためにはとりあえず大学教養レベルからちゃんと学び直す必要があると感じていたので,いい機会だと思い,受験を決めました.

やったこと

2017年3月

この時点では,2-3週間ほど勉強した上でCBT試験を受けようと思っていた.

とりあえずテキストと過去問を買う.

改訂版 日本統計学会公式認定 統計検定2級対応 統計学基礎

改訂版 日本統計学会公式認定 統計検定2級対応 統計学基礎

以前の記事でも言及したが,このテキスト,解説に不十分な箇所が多く,あまり評判がよくない.
結果的にこのテキストはあまり使わず,試験日前日に試験範囲の勉強に漏れがないかチェックするためだけに使った.

日本統計学会公式認定 統計検定 2級 公式問題集[2014〜2016年]

日本統計学会公式認定 統計検定 2級 公式問題集[2014〜2016年]

日本統計学会公式認定 統計検定 2級 公式問題集[2013〜2015年]

日本統計学会公式認定 統計検定 2級 公式問題集[2013〜2015年]

逆に,こちらの過去問*3は,実際の検定の問題とその簡単な解説を並べている,非常にシンプルで読みやすい本だった.
これを数回回して,理解が十分でない点を他の参考書等で補うのが基本的な学習の流れになるかと思う.
また,一読すれば,ここ数年は回を経るごとに問題が難化する傾向にあったことと,推定・検定からの出題が減って,確率分布についての出題が増えていることも見て取れるか.

2017年4月

若干仕事が忙しくなり,ズルズルと受験を引き伸ばしていた.
こういう時,「いつでも受けられる」試験は申し込みボタンを押すまでのモチベーションが保てないので厳しい.

そうこうしている間にいつの間にか6月のPBT試験の受付が始まっていたので,えいやで申し込む.

2017年5月

GWで英気を養ったので,勉強を再開.

せっかくやるからには,ただ問題を解くだけでなく数学的な背景も知りたいと思ったので,統計入門の名著である「赤本」を買った.

統計学入門 (基礎統計学?)

統計学入門 (基礎統計学?)

評判通り,基礎教養としての統計学として学ぶべきことが過不足なく体系的にまとまっており,昔受けた講義の内容を思い出すのに役立った.
決してカンタンに読み進められる本ではないが,出て来る数式についてはわりと補足があり,必要に応じて例示によって理解を促す構成になっているので,自分のような数式が苦手な人間にもありがたい.
統計検定2級と範囲がかぶっているので,これを一読した上で過去問を解いていくだけで合格点を取れる実力は十分につくかと思う.
一点いちゃもんをつけると,回帰分析についての内容が十分でなく,分散分析は内容に含まれていないので,そこはWebページや他の本で補う必要がある.

また,計算問題を解くに当たって,家に眠っていた

スバラシク実力がつくと評判の確率統計キャンパス・ゼミ (大学数学「キャンパス・ゼミ」シリーズ)

スバラシク実力がつくと評判の確率統計キャンパス・ゼミ (大学数学「キャンパス・ゼミ」シリーズ)

の演習問題を使った.

検定の問題では,計算問題がそれなりに出るが,これが結構面倒で,どうしても計算ミスが多くなってしまう.
特に,分散・共分散の計算では,計算式をうまくいじくることで計算過程を大幅に省略できることがあるので,実際に練習問題にあたって式を追っておくことは重要だと思った.

Webページとしては,

bellcurve.jp

が,統計検定2級の範囲を網羅しており,解説も具体例をベースとした非常に理解しやすいものであり,非常にお世話になった.
自分は気づくのが遅かったので実行しなかったが,このページベースで学習を進めるのは大いにアリだと思う.

2017年6月

試験場には「四則演算(+-×÷)や百分率(%)、平方根(√)の計算ができる一般電卓又は事務用電卓」の持ち込みが認められているが,電卓が家にないことに気づいたので買った.

電卓使うのすごく難しかったのでたぶん自分はデジタルネイティブ世代なんだと思う…

試験当日

某大学での受験だったが,入口の門がことごとく閉まっており,入れる入口を探し回ったことからわりとギリギリの到着になってしまった.

全体的には,2016年の試験より簡単に感じられた.
重箱の隅をつつくような出題が減り,基本的な知識を問う問題に回帰しているような気がした.

一問,例年の傾向から外れて分散分析の範囲から問題が出題されたが,ちょうど直前に対策をしていたので解くことができた.ラッキー.

結果

数日後に正解が発表されるので,自己採点してみたところ32/35.
6割が合格ラインとされているので,マークミス等なければ合格はしたかな,と思っていました.

およそ3週間後にWebでの合格発表がありました.
統計検定では,最優秀成績者に評価S,優秀成績者に評価Aの評価と表彰状が与えられますが*4,評価Sをいただくことができました.

f:id:lethe2211:20170722000604j:plain


こんな感じでした.

全体的な感想として,表面的に教科書を読んでいるだけでは理解できない,しかしよく本質をついた問題が出題されていたように思います.
特に,データから特徴を見抜いたり,世の中によくある試行からその確率分布を導く問題などは,数学の世界と実世界を結びつける,良い問題だと感じました.

受験後,ちらっと準1級の問題を見てみましたが,やはり結構難しそうなので,2級から受けてよかったと思っています*5

少しづつ統計の知識も身につけていきたいです.

*1:なので,学生であれば,講義内容の予習,復習がてら受けてみる,という使い方もできるかもしれない.逆に,この辺の講義を受けたことがない人がそのまま2級を受けるのは少し厳しいので,自習するか,3級からはじめることを勧める.

*2:学士・修士の研究でちょっとだけデータまとめをした程度.

*3:過去問については,http://www.toukei-kentei.jp/past/#pastpaperに過去1回分がUPされる.世の中にはInternet Archiveというモノがあっておっと誰か来t(ry

*4:こういうの,他の検定試験ではあまり見かけない気がする.

*5:準1級から上はPBTのみで,かつ年1回であることに注意.

情報処理安全確保支援士になった

www.ipa.go.jp

www.ipa.go.jp

なってみました(個人情報は晒していません).

なぜ?

一言で言うと,「士業」という職(?)を経験してみたかったから.

今まで,日本のIT業界には国家資格はいくつかあったものの,名称独占の認められる「士」のつく職はありませんでした*1
また,在野のエンジニアでいるのも別に悪い気はしないのですが,ちょっとまわりの人間と差をつけるための箔をつけたいという下心のようなものがあったのも事実です.
ちょうど有資格者に含まれていたということもあり,軽い気持ちで取ってみようかなと.

あと,情報セキュリティについてわりと本気で学んでみたいという気持ちもありました(ウソじゃありません).
一口に情報セキュリティと言っても,「怪しい内容のメールを開かない」のような非常にローテクなものから,CTFで扱われるようなガチガチのリバースエンジニアリング*2までいろいろあります.
自分は前から,特定のプログラミング言語や技術スタックを突き詰めるタイプのエンジニアというよりは,広く浅い知識で世渡りしていく感じが向いているんだろうなぁと思っていました.
こうした国家資格であれば,幅広く知識をつけられるのではないかなと思ったのも動機の1つです.

「3年で15万」の更新/講習料,高くない?

まだ払い込んではいませんが,正直そんな気はしてます…

現実的に有資格者の数から考えると,4,000人強という数は本当に少ない気がします.
たぶんみなさん様子見してるんでしょうね…

個人的に期待しているのは,講習の内容そのものというより,そのへんを通して横のつながりのようなものができるかなぁというところです.
自分自身セキュリティにそこまで詳しいわけではないので,ぜひ詳しい人におんぶにだっこしたいものです.

これからの流れは?

とりあえず1年以内をメドに,オンラインの講習と集合研修の2つを受ける必要がありそうです.
内容については知らされていないので全然わかっていませんが,ここらへんの難易度等を見て,今後の身の振り方を考えていきたいと思います.

f:id:lethe2211:20170404215531j:plain

*1:正確に言うと技術士情報工学)があるけれど

*2:たぶんこの資格では扱われないですよね…

最近読んだ本

今年の1~3月ぐらいで読み終えた本を晒しておきます.
ここに挙げているものはすべて(シリーズ物については全巻)読了したものです.

改訂版 日本統計学会公式認定 統計検定2級対応 統計学基礎

改訂版 日本統計学会公式認定 統計検定2級対応 統計学基礎

改訂版 日本統計学会公式認定 統計検定2級対応 統計学基礎

統計検定2級の公式テキスト.

www.toukei-kentei.jp

統計学は以前から勉強したいと思っていたので,とりあえず大学教養レベルぐらいの知識は欲しいと思って少しづつ勉強している.
一応目を通したが,数式や図による説明が少ないのと,結論だけを示してそこに至る過程を示していないことが多く,検定試験のテキストとしても統計学の解説本としても中途半端な印象だった*1

日本統計学会公式認定 統計検定 2級 公式問題集[2014〜2016年]

日本統計学会公式認定 統計検定 2級 公式問題集[2014〜2016年]

日本統計学会公式認定 統計検定 2級 公式問題集[2014〜2016年]

代わって,こちらの公式問題集は,実際の検定の問題とその(簡単な)解説を並べているだけなので非常に読み進めやすかった(まだ全部読めてないけれど).
もっとも,解説自体はそこまで詳しくないので,適宜他の教科書等で補っていきたい.

検定自体はいつ受けよう…?

夜行

夜行

夜行

直木賞ノミネートもされた森見登美彦の作品.
正月の実家ぐらしがあまりにもヒマだったので読んでみた.

10年ぶりに再会したかつての英会話スクールの仲間が,それぞれに起こった不思議な出来事を話していく,という連作形式の物語.

序盤の不気味ながらもゆっくりとした物語進行から,クライマックスのどれが夢でどれが現実かわからなくなるようなめくるめく展開には驚かされた.
1つ1つの話にはいわゆる「キレイなオチ」みたいなものはないのだが,それがさらに物語の不気味さを加えている.

夜は短し歩けよ乙女」や「四畳半神話大系」などで作者のことを知っている人にも一度読んでもらいたい.

know

know (ハヤカワ文庫JA)

know (ハヤカワ文庫JA)

ビッグデータ」を話題にしたSF小説があると聞いて興味を持ったので読んだ.

ありとあらゆるものが「情報」で構成され,その膨大な情報を処理するための「電子葉」と呼ばれる装置を脳に埋め込むことが一般的となった近未来の冒険活劇.
物語の内容自体はよくある「俺(のことが好きな女の子)TUEEEE」なのだが,「持っている情報量」と「その処理速度」がすべてを制するという設定がIT系SF好きの自分としては興奮せざるを得なかった.
1巻完結なので展開も早く,先が気になって一気に読み終えてしまった.
SF初心者にオススメ.

いちばんカンタン!株の超入門書 改訂版

いちばんカンタン!株の超入門書 改訂版

いちばんカンタン!株の超入門書 改訂版

株を始めたくなったのでとりあえず買ってみた.

銘柄の探し方から買い時,チャート分析など,内容自体は非常にわかりやすく解説されていて,「ふーんなるほど」とは思えた.
たぶん,ちゃんと株を始める人たちは,これで外観をつかんで他の入門書に進んでいくのだと思う.
読んだ後すぐに実践したくなったので早くNISA口座出来てくれ.

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

達人に学ぶDB設計 徹底指南書

達人に学ぶDB設計 徹底指南書

だいぶ前の翔泳社Kindle40%引きセールで買ったまま長い間積読だったが,旅行でヒマだったので読んでみた.

大きく分けて,正規化,ERモデリングなど,大学の情報系学部で学ぶようなリレーショナルデータベースについての基礎理論の解説部分と,実際にデータベースを運用する際に必要な(グッド,グレー,バッド)ノウハウの解説部分で構成されている.
一応大学ではデータベースを勉強していたので読んでいてあまり詰まる部分はなかったが,基本的な知識の復習と,「この設計なんかダメそうだけどなにがダメなんだろう」について自分の中で整理ができたように感じる.
特定製品についての話は少なく,(特に前半部分は)IPAデータベーススペシャリスト試験の内容に近いので,副読本としての利用も可能ではないかと思う.
個人的には,スキーマ設計についてはそこそこに,インデックスやデータ型定義の設計ノウハウについてもう少し補足してもらいたかったところ.

嫌われる勇気

嫌われる勇気―――自己啓発の源流「アドラー」の教え

嫌われる勇気―――自己啓発の源流「アドラー」の教え

一度心理学を勉強してみたかったので読んでみた.

読んでみた感想としては,「自己啓発本としてはよかった」という感じ.
特に,「トラウマなど存在しない.自分の今の状態の原因を過去に求めるのではなく,今自分がどうなりたいかを考えて行動しろ」(意訳)という部分はなかなか刺さった.
加えて,アドラー心理学を学んだ「哲人」と自分に思い悩む「青年」の対話形式で書かれていることも特徴的である.
「青年」による反駁によって,単なる意見の押し付けにならず,かつより読み進めやすくなる構成になっていた.
ところで,本書中でも述べられているように,本書はアドラー心理学そのものではなく,原案の岸見一郎氏の考えを取り入れた「岸見アドラー学」について説明しているものであることにも注意.

心理学の本としては学びはあまりなかったように感じるので,もっと学術寄りの本にも手を出してみたい.

*1:端的にいうと「文字ばかり」