AWSソリューションアーキテクトアソシエイト(SAA-C02)受験体験記
概要
AWSソリューションアーキテクトアソシエイトの試験に合格しました。勉強期間は4週間ほどでした。幸い1回目の試験で合格することができました。勉強方法や試験の流れをメモしておきたいと思います。
モチベーション
勉強期間は少し特殊な状況でした。2020/10に第2子が生まれたのをきっかけに、会社の制度（妻出産休暇）を利用して4週間の休暇をいただきました。この1ヶ月はほぼ専業主夫状態で、家事全般と上の子（5歳）の世話をしてました。休暇といってもそんな感じなので、まとまった時間を取るのは難しいと思っていましたが、平日は上の子が保育園に行っている間に隙間時間があるかなと思ったので、何か資格でも取ろうかなと思っていました。
私はインフラエンジニア歴は長い部類ですが、クラウドの体系的な勉強はしたことがなかったので、AWSの勉強をしてみようと思いました。体系的に勉強するなら資格の勉強をするのがよいと思ったので、AWSの資格を取得してみようと思いました。AWSソリューションアーキテクトアソシエイトは、AWSの資格の中では中級程度に位置づけられる資格で、AWSのサービスを比較的幅広く理解している必要があります。今は業務上で開発や構築を本格的に行う機会は少ないですが、クラウドについて理解している必要はあるので、私に合っているかなと思いました。
勉強方法
勉強に用いた教材を紹介します。
私は主にこの教材で勉強しました。定価は12000円ですが、私が購入したときは1800円くらいでした。Udemyは毎月のように9割引とかのセールをやっているので、セールのタイミングで購入するのがいいと思います。最安だと1200円くらいになります。（定価っていったい...）
このコースでは、ハンズオン形式で実際のAWSのサービスに触れながら学習を進めることができます。今回は、試験に合格することよりも、AWSの様々なサービスに体系的に触れることが目的だったので、ハンズオン形式で勉強できるのがよかったです。AWSをあまり使ったことがなくても、インフラの知識がある程度あれば、タイトルのとおりこれだけで合格することは十分に可能だと思います。
AWSでは頻繁なサービスの変更がありますが、AWSのサービス変更に追随して、こちらのコースの教材も頻繁にアップデートされているようです。変更があった部分は都度説明が追加されていて親切だと思いました。画面が現行のサービスと多少異なる部分もありますが、AWSを使うならその程度は気にしない方がよいということだと思います。
AWSでは高額のサービスも簡単に使えてしまうので、気をつけないと後で高額の請求に驚くということになることがあります。勉強代とはいえ何万円もかかってしまうのはつらいですが、ある程度経験がないと勘所がわかりにくいと思います。このコースでは、月額だと何万円にもなる高額なサービスも使うことがありますが、高額なサービスは使用後すぐに削除するようにアドバイスしてもらえるので、AWSのコストは最小限で済みます。会社等でAWSを使える場合もあると思いますが、このコースではルートアカウントを使ったりするので、できれば自分でアカウントを作って、自分のクレジットカードでコストを気にしながら使った方がよく身につくんじゃないかと思います。結果的に、コース開始から終了まで約3週間使いましたが、AWSのコストは2.09米ドルでした。コーヒー1杯分くらいなので、このくらいなら安心して使えるのではないかと思います。
コストの内訳は以下のようになりました。
EC2が多いですが、EC2自体ではなくNATゲートウェイのコストが高めでした。EC2自体は無料枠で済んでいました。Elastic IPも少し課金されてますが、デタッチして放置してしまったことがあったので課金されてしまいました。デタッチしてすぐに解放すればもう少しコストを抑えられると思います。数十円なので誤差みたいなもんですが。
上記のハンズオンにも2回分の模擬試験が付いていますが、さらに6回分の模擬試験を収録した問題集です。こちらも割引があるときに1200円くらいで購入しました。難易度はやや高めなので、これで7割前後得点できていれば本番でも合格できる可能性が高いと思います。
こちらは試験用の教材ではありませんが、AWSソリューションアーキテクトの原典とも言える文書です。技術的なことだけでなく、組織やビジネスのあり方についても書かれていて、AWSの利用者に限らず役に立つと思うので、目を通すといいと思いました。
申し込み～試験
AWSの試験はベンダ系のIT資格でおなじみのピアソンで受験することができます。ウェブから都合のよい日を自分で選んで予約することになります。AWSの試験は、今ではオンラインでも受験することができるようになっていますが、周りに何もない部屋を用意しないといけないなど、私の自宅ではちょっと難しく、東京駅近くの試験センターに行って受験しました。
試験時間は140分です。140分で65問なので、まあまあ余裕があります。70分ほどで全問に解答し、自信がない問題にはマークを付けました。全問回答後、20分ほどでマークした問題を見直し、さらに20分ほどで全問を見直しました。12問ほど自信がない問題がありましたが、8割程度は得点できているだろうと判断し、30分ほど残して試験終了にしました。試験が終わると画面上で合否を確認することができます。無事に合格と表示されていたのでひとまず安心しました。
試験の言語は日本語で受験しましたが、画面上で英語も確認することができます。外資系ベンダの試験としてはそれほど変な日本語ではなかったかなと思いますが、ところどころサービス名や機能名の訳が実際のサービスと異なっているところがありました。日本語に違和感があったら英語を見てみた方がよいと思います。実際にAWSを使うなら英語のドキュメントを読むこともあると思うので、あまり細かいことは気にしない方がいいということだと思います。
合格後の対応
合格の翌日、正式な合格通知がメールで送られてきました。スコアは1000点中775点でした。8割くらいかなと思ったので想定の範囲内ですが、あまり余裕はなかったみたいです。合格するとこんな感じのロゴがもらえます。
試験に合格すると、模擬試験の無料での受講や、次回の試験の割引などの特典があるので、他の資格の取得を狙ってみてもいいかもしれません。試験に合格はしたものの、AWSのサービス一覧を見ると全く知らないサービスが山のようにあって正直なんもわかりません。AWSサービス多過ぎです。継続的な学習が必要かなと思います。
Kata Containers on Oracle Linux について Oracle Open World でお話ししてきました
概要
2019/9にサンフランシスコで開催されたOracle Open World 2019で登壇する機会をいただきました。Linuxとセキュリティという切り口で、Oracle LinuxのPMのSimon Coterさんといっしょに、Kata Containersというセキュリティ指向のコンテナランタイムについてお話ししてきました。
実は英語で登壇するのは初めての経験だったので、出落ちのクレイジージャパニーズくらいの気持ちで行きましたが、それなりに形になってたようです。我ながらかなりの変態ミッションだったと思います。
- 夏休みの個人旅行でOracle Open Worldに行く
- 個人で登壇する
- 英語で30分ぐらい話してデモもやる
- アイスブレイクでけん玉をちょっとやる
Oracle Open Worldに登壇した日本人はいっぱいいますが、けん玉をやった人はいないでしょう。
Oracle Open World 2019 の資料はこちらのサイトからダウンロードできます。（英語版です）
2019/8に日本で開催された、Oracle Modern Cloud Day Tokyoでも、同じ内容を日本語でお話しさせてもらったので、そちらの資料を使って解説したいと思います。
Oracle Modern Cloud Day Tokyo の資料はこちらのサイトからダウンロードできます。
https://www.oracle.co.jp/campaign/moderncloudday/2019/
導入
表紙の背景に特に意味はありませんが、自分で撮影してきた天体写真をぶっ込むスタイルでいきました。この写真は2017年8月にアメリカで撮影してきた皆既日食の写真です。OOWで皆既日食を見た人がいるか聞いてみたら、2,3人手を上げてくれました。
余談ですが、2017/8/21 北米皆既日食の記事はこちら。
自己紹介スライドはいつもながら自己主張強めです。OOWではちょっとけん玉やりました。だいぶうけてたのでアイスブレイクには成功したようです。芸は身を助ける、です。
アプリケーションコンテナ
コンテナ型仮想化の歴史は、1979年にUnixに実装されたchrootに遡ります。chrootはプロセスからファイルシステムを隔離する仕組みで、今でもよく使われます。2000年には、FreeBSDでJailという仕組みが導入されました。これはchrootをさらに強化したもので、プロセス空間も隔離します。Jailによって、OSの中に仮想OSを作るような使い方ができるようになりました。2005年には、Solaris 10でSolaris Zones (Solaris Containers)という仕組みが導入されました。これはほぼ仮想サーバのような機能で、ZonesがあるからSolarisを使っていた方も多いんじゃないかと思います。Solaris 11では、Kernelまで隔離した、Kernel Zonesというほぼハイパーバイザのような機能も導入されました。
またも余談ですが、2014年にSolarisのVPのBill Nesheimさんといっしょに、Solarisの仮想化についてお話ししたことがありました。我ながら、面白い機会をいただいていてありがたいことです。 www.sbbit.jp
Linuxでのコンテナ型仮想化も歴史が長く、2000年代半ば頃から、OpenVZ/Virtuozzoや、Linux-Vserverがレンタルサーバなどによく使われていました。初期のDockerでも使われていたLXCや、LXCを便利にした感じのLXDや、systemdに統合されたsystemd-nspawnなど、様々な実装があります。 2013年にDockerが登場してからアプリケーションコンテナが一気に広まってきました。2014年にKubernetesが登場し、今回紹介するKata Containersは2017年に登場したかなり新しい技術です。
今ではすっかり、「コンテナ」と言えば「アプリケーションコンテナ」のことを指すようになってしまいましたが、私は単に「コンテナ」と言うと、コンテナ型仮想化（OSレベル仮想化・システムコンテナ）の方を想像してしまうので、なるべく「アプリケーションコンテナ」と言うようにしていたりします。コンテナ型仮想化は、仮想サーバと同じような使い方をしますが、アプリケーションコンテナはその延長線上にはないのではないかと思います。
アプリケーションコンテナと従来のコンテナ型仮想化は似ていないと言いましたが、アプリケーションコンテナはサーバ仮想化などのインフラの話よりも、アプリケーション開発やDevOpsの文脈で語られることが多いのではないかと思います。Dockerの典型的な使い方としては、ビルド、パッケージング、デプロイという流れになると思いますが、昔からあるサーブレットコンテナととてもよく似ていたりします。アプリケーションコンテナとは、仮想サーバを置き換えるものではなく、アプリケーションをデリバリするためのものであると捉えるのがわかりやすいと思います。
アプリケーションコンテナのセキュリティ
ガートナーが最近出しているリサーチによると、2019年時点で、アプリケーションコンテナを商用で使っている組織は、ワールドワイドで30%未満とのことです。しかし、2022年にはこれが75%超になると予想されています。 会場の方に、アプリケーションコンテナを商用で使っているか聞いてみたところ、日本のModern Cloud Dayでは10%未満でしたが、アメリカのOpen Worldでは30～40%くらいの方が手を上げました。ガートナーのリサーチはそれなりに当たっていそうな感じです。 ガートナーは同じ記事の中で、アプリケーションコンテナを商用で使うための、6つの重要な要素を挙げていて、その1番目に「セキュリティ＆ガバナンス」を挙げています。
アプリケーションコンテナのセキュリティと一言に言っても、どうすればいいのかなかなか難しいです。NIST（米国国立標準技術研究所）がよくまとまった文書を公開しているので、そちらを参照してみましょう。NIST SP800シリーズはセキュリティ関連の文書で、SP800-190 はアプリケーションコンテナのセキュリティについてまとめられています。2017年9月に公開されたものなので、かなり新しい文書です。 その中で、アプリケーションコンテナの典型的なアーキテクチャは上の図のようなコンポーネントから成り立っていると述べられています。図の左から、開発者がコンテナイメージを作って、テストして、レジストリに登録して、管理者がオーケーストレータを使ってホストにデプロイする、という流れになっています。Docker、Kubernetes、DockerHubなどは、このアーキテクチャの実装例といえます。
SP800-190はこちらからダウンロードできます。 csrc.nist.gov
一部の文書はIPAが日本語化して公開しています。SP800-190はまだないようです。 www.ipa.go.jp
同文書の中で、アプリケーションコンテナには5つの主要なリスクがあると述べられています。5つのリスクとは、イメージのリスク、レジストリのリスク、オーケストレータのリスク、コンテナランタイムのリスク、ホストOSのリスクです。
コンテナイメージの中身は、概ね上のような図のようになっています。先ほど、アプリケーションコンテナはアプリケーションをデプロイするためのものだと述べました。誤解を恐れずに言えば、アプリケーションの開発者はほぼアプリケーションにしか興味がないことが多いんじゃないかと思います。でも、コンテナの中身はOSイメージそのものなので、インフラやセキュリティの人は、ライブラリやユーザランドが気になってしまうのではないかと思います。 でも一般に、アプリケーションコンテナの場合は、中に入ってプロセスを監視したりログを監視するようなことはあまりやりません。むしろお行儀が悪いと言われたりします。これは仮想サーバのように使うコンテナ型仮想化の場合とは異なるやり方が必要になりますが、セキュリティとしてはコンテナイメージの中身も見る必要があります。DevOpsにセキュリティを加えたDevSecOpsのような考え方が必要になるということだろうと思います。
次に、ホストOSのリスクの中の、Kernelの共有の項目に注目したいと思います。一般的に、アプリケーションコンテナ環境では、アプリケーションレベルで隔離が行われているものの、Kernelを共有しており、ハイパーバイザによる仮想化より隔離のレベルが低いと考えられます。Kernelを共有しているので、1つのアプリケーションコンテナが侵害されれば、ほかのアプリケーションコンテナもリスクにさらされる可能性が高いといえます。この手の攻撃が刺さる可能性はそう高くないかもしれませんが、カーネルを共有していることがセキュリティの論点になることはあるということです。
Kata Containers
Kernelの共有がセキュリティのリスクになることがあるということから、ようやくKata Containersの話に入ります。ハイパーバイザの技術を利用し、 アプリケーションの強い隔離を実現するコンテナランタイムで、OpenStack Foundataion（OSF）がサポートしています。2017/12に出たばかりのとても新しい技術です。 コンテナオーケストレータは、今のところKubernetesがデファクトスタンダードといえますが、一方、コンテナランタイムはいろいろな特性を持ったものが出てきています。Kata Containersはかなりセキュリティに振り切ったコンテナランタイムだと言えます。
この図は、Kata Containersのアーキテクチャを模式図にしたものです。一般的なコンテナランタイムでは、左の図のように、Kernelを共有して、Namespaceの機能でアプリケーションを隔離します。それに対して、Kata Containersでは、アプリケーションコンテナ毎にKernelが分離するので、ハイパーバイザによる仮想化と同等の隔離を実現しています。
この図は、DockerとKata Containersの関連性を表したものです。kata-runtimeはLow-Levelのコンテナランタイムです。また、CNCFが策定したOCI Runtime Specificationに準拠しています。Dockerでは、通常runCがLow-Levelコンテナランタイムとして使用されますが、もちろんrunCもOCI Runtime Specificationに準拠しています。つまり、runCをkata-runtimeに置き換えることが可能ということになります。Kata ContainersはDockerやKubernetesを置き換えるものではなく、組み合わせて使うものと考えるのがよいと思います。
Kata Containersは、Oracle Linuxでは Oracle Linux Cloud Native Environment (OLCNE) の一部として取り込まれています。とはいえ、OLCNEという製品があるわけでもなく、サービスがあるわけでもありません。Oracle Linuxには、クラウドでのアプリケーション開発や運用に必要な機能がバンドルされているという、コンセプトのようなものだと私は理解しています。
Demo
こんな感じの環境で簡単なデモを行いました。仮想化にはVMware Playerを使いましたが、Oracle LinuxのPMのSimonさんは、VirtualboxのPMでもあるので、できればVirtualboxを使いたいと思っていました。Kata ContainersはKVMを使うので、仮想環境で動かすには、Nested VMができる必要があります。Virtualbox 6.0でAMDのCPUではNested VMに対応しているのですが、IntelのCPUではまだ対応していませんでした。VMware PlayerではIntel CPUでもNested VMができました。Virtualbox 6.1では、Intel CPUでもNested VMに対応予定のようなので、期待したいと思います。 イベントでは機材トラブルがつきものなので、デモをやるのは度胸が必要です。幸い日本でもアメリカでもデモ環境はすんなり動いてくれてよかったです。
デモのシナリオです。Docker Hubから取得した、Nginxのイメージを、Docker+runC と Docker+kata-runtime でそれぞれ起動するというデモを行いました。docker run の --runtime オプションを指定するだけで、必要に応じてコンテナランタイムを切り替えることができ、混在させることもできます。 Solaris 11をよく知っている方は、Native ZonesとKernel Zonesとの関係に似ていると考えるとわかりやすいんじゃないかと思います。
Oracle LinuxでKata Containersを使うのはわりと簡単です。この手順は、Developer Previewでの手順なので、GA(General Availability)になったら変わるかもしれませんのでご了承ください。
# yum-config-manager --enable ol7_addons # yum-config-manager --enable ol7_developer # yum-config-manager --enable ol7_developer_kvm_utils
必要なRPMをインストールします。
# yum install docker-engine # yum install qemu # yum install oracle-olcne-release-el7 # yum install kata-runtime
Dockerの起動オプションを変更して、kata-runtimeを有効にします。
# vi /etc/sysconfig/docker --- OPTIONS='-D --add-runtime kata-runtime=/usr/bin/kata-runtime' # systemctl restart docker
Kata Containersを使用するには、KVMが有効になっている必要があります。
# lsmod … kvm 643072 1 kvm_intel
設定がうまくいっていれば、docker info でランタイムが追加されているのがわかります。
# docker info … Runtimes: kata-runtime runc
docker run でコンテナを起動すると、runCの場合は1秒くらいで起動しますが、kata-runtimeは仮想マシンを起動するので4～5秒くらいかかりました。パフォーマンスのテストは詳細にはやっていませんが、KVMで仮想化しているのと同じくらいのオーバーヘッドはあると考えられます。 pstreeでプロセスを見ると、runCのほうはNginxのプロセスが見えているのに対して、kata-runtimeのほうは、qemuのプロセスが見えて、たしかに仮想化されているのがわかります。Nginxのプロセスは仮想マシンの中なので、ホストOSからは見えなくなっています。
まとめ
というわけで、アプリケーションコンテナを商用環境で使うときにはそれ相応のセキュリティを考慮する必要があるということと、Kernelの共有はセキュリティリスクとして論点になりうるという話から、ハイパーバイザの技術でアプリケーションコンテナを隔離するKata Containersというコンテナランタイムについて紹介しました。今後、Kata Containersが主流になるかはまったくわかりませんが、コンテナランタイムは必要に応じて特性の違うものを使い分けるようなケースが増えてくるのではないかと考えています。
またも余談ですが、最後のスライドも自分で撮影してきた天体写真をぶっ込みました。2018年に、世界有数の美しい星空だと言われる、ニュージーランドのテカポ湖で撮影してきた天の川の写真です。 ニュージーランド旅行の記事はこちらから。 shakemid.hatenablog.com
Elasticsearch Cluster on Linux Container
概要
Linuxコンテナ（systemd-nspawn）を使って、複数ホストにまたがるElasticsearchクラスタを構築してみました。 私はコンテナ歴12年くらいですが、ほとんどSolarisコンテナ（Zones）ばかり使っていて、Linuxコンテナはどんなものかよくわかっていないので、おかしなことを言っていましたらご指摘ください。
背景
以下のような感じの要件で、基盤のアーキテクチャを考えていました。
- 50～100ノード規模のElasticsearchクラスタを作りたい
- オンプレ環境で
- 一度起動したら年単位で動き続ける
- 商用ライセンスはあまり使いたくないけど、人柱になって自力でなんとかする気概はあり
なんとなく以下のような実現方式を考えました。本音はSolaris Zonesを使いたくてたまりませんが今回はLinux縛りです。
| カテゴリ | 方式 | 評価（主観） |
|---|---|---|
| 物理系 | 物理サーバ50台 | × ラックが足りない。運用嫌だ。 |
| 物理サーバ＋マルチプロセス | △ 運用嫌だ。 | |
| ハイパーバイザ系 | VMware | △ ライセンス必要。オーバーヘッド嫌だ。 |
| KVM, Xen | △ オーバーヘッド嫌だ。 | |
| コンテナ系 | Docker | △ どうも合わない。k8s, Swarmとかは大がかりすぎ。 |
| OpenVZ | △ まだあるのだろうか？ | |
| LXD | ○？ 良さそう。使うならUbuntuが良さそうか。 | |
| systemd-nspawn | ○？ ほぼOS標準の機能！ |
Dockerは少し検証してみたのですが、動くには動くのでしょうが、ホストまたぎのネットワークを構成するのが面倒で、KVSを立ち上げて、VXLANでオーバーレイネットワークとかになるのでやる気がなくなりました。 そのためだけにKubernetesとかSwarmを使うのも大がかりすぎに思えました。
DockerをDisる気はなく、用途がマッチすれば良いと思いますが、仮想マシンのようなことがやりたいならまったく不向きで、無理矢理使っても悲惨な運用になるのが落ちという感じがします。 長年Solarisコンテナを使ってきたのもあって、なるべくシンプルでほぼOS標準の機能で動作するということから systemd-nspawn にたどり着き、検証してみようと思いました。
なお、クラウド前提なら、Amazon Elasticsearch Service を検討するのもいいと思います。
シナリオ
今回構築する環境は以下のようなイメージです。物理マシンがあれば使ってもいいですが、私はVirtualBox上に構築することにしました。
構築は以下のような流れで進めました。
- ホスト構築編
- コンテナ構築編
- コンテナイメージをインストールする
- コンテナを起動する
- Elasticsearchをインストールする
- コンテナをコピーする
構築
ホスト構築編
CentOS 7 をインストールする
OSはユーザが多いであろうCentOSにしました。バージョンは現時点で最新の7.6にしました。
インストールはできましたが、グラフィカルインストーラだとマウスでボタンをクリックできないことがある謎の事象に遭遇したので、テキストインストーラを使う方がいいような気がします。
今回はホスト間で通信できる必要があるので、VirtualBoxのネットワークの設定でブリッジアダプターを使うとよいと思います。また、プロミスキャスモードを許可する設定も必要です。
また、OSの領域とコンテナの領域を分けたいので、ストレージの設定画面でディスクイメージを1つ追加しました。
SELinuxは無効にしました。
$ sudo vi /etc/sysconfig/selinux ---- ... SELINUX=disabled ...
systemd-networkd をインストールする
今回はホスト間で通信できるようにネットワークブリッジを使うので、ネットワークの管理をsystemd-networkdで行うのがよいようです。以下のページを参考にしました。
以下のページも参考にしました。systemd関連のドキュメントはArch Linuxのものがわかりやすい感じがします。
systemd-networkd と systemd-resolved をインストールします。
$ sudo yum install systemd-networkd systemd-resolved
設定ファイルを作成します。内容は環境に合わせて適当に変えてください。Redhat標準の /etc/sysconfig/network-scripts/ 以下のファイルは使われなくなります。
/etc/systemd/network/br0.netdev ---- [NetDev] Name=br0 Kind=bridge
/etc/systemd/network/enp0s3.network ---- [Match] Name=enp0s3 [Network] Bridge=br0
/etc/systemd/network/br0.network ---- [Match] Name=br0 [Network] Address=192.168.0.10 Gateway=192.168.0.254 DNS=192.168.0.254
systemd-networkd と systemd-resolved を有効にします。
$ sudo systemctl disable network NetworkManager $ sudo systemctl enable systemd-networkd systemd-resolved $ sudo reboot
resolve.conf を入れ替えておきます。
$ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
networkctl コマンドで、IPアドレスなどを確認することが出来ます。
$ networkctl status
● State: routable
Address: 192.168.0.10 on br0
Gateway: 192.168.0.254 (XXX) on br0
DNS: 192.168.0.254
ZFS をインストールする（任意）
ZFSは必須ではありませんが、コンテナの領域を管理するのに都合が良さそうなので使ってみたいと思います。 systemd-nspawn はBtrfsと連携する機能があるようなのですが、ここは慣れ親しんだZFSにします。
ZFSをCentOSで使用するには、カーネルモジュールを追加する必要があります。ZFS on Linux の公式の手順に従ってインストールします。
$ sudo yum install http://download.zfsonlinux.org/epel/zfs-release.el7_6.noarch.rpm
zfs-kmod のほうを有効にします。
$ sudo vi /etc/yum.repos.d/zfs.repo ---- [zfs] name=ZFS on Linux for EL 7 - dkms baseurl=http://download.zfsonlinux.org/epel/7/$basearch/ -enabled=1 +enabled=0 metadata_expire=7d gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-zfsonlinux @@ -9,7 +9,7 @@ [zfs-kmod] name=ZFS on Linux for EL 7 - kmod baseurl=http://download.zfsonlinux.org/epel/7/kmod/$basearch/ -enabled=0 +enabled=1 metadata_expire=7d gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-zfsonlinux
ZFS をインストールします。
$ sudo yum install zfs
ARCのサイズを制限しておきます。
$ sudo vi /etc/modprobe.d/zfs.conf ---- options zfs zfs_arc_max=1073741824
ストレージプールを作成します。ZFS on Linux では、ls -l /dev/disk/by-id で表示されるデバイスIDを使用することが推奨されているようです。
$ sudo zpool create tank ata-VBOX_HARDDISK_XXXXXX-XXXXXX
tank という名前でストレージプールができました。
$ zpool list NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT tank 39.8G 291K 39.7G - 0% 0% 1.00x ONLINE -
コンテナ用の領域（データセット）を作成します。compressionの設定はお好みに合わせてという感じです。近年はCPUが高速なので、圧縮した方が Disk I/O が減って高速になるケースもあります。
$ sudo zfs create -o compression=lz4 -o mountpoint=/var/lib/machines tank/machines $ sudo zfs create tank/machines/es11 $ sudo zfs create tank/machines/es12
こんな感じでデータセットができました。
$ zfs list NAME USED AVAIL REFER MOUNTPOINT tank 162K 38.5G 25.5K /tank tank/machines 73K 38.5G 25K /var/lib/machines tank/machines/es11 24K 38.5G 24K /var/lib/machines/es11 tank/machines/es12 24K 38.5G 24K /var/lib/machines/es12
systemd-nspawnでは、 /var/lib/machines/ 配下のディレクトリ名がコンテナのhostnameになるように想定されているようです。長さの制限は一見ないように見えるのですが、systemd-networkd がインタフェース名を自動生成するときに先頭11文字で切り落としてしまうようで、先頭11文字がユニークでないと名前が衝突するようです。そのうち改善するのかもしれませんが、ディレクトリ名（コンテナ名）は11文字以下にするのが無難なようです。
コンテナ構築編
コンテナイメージをインストールする
systemd-nspawn では、コンテナイメージをインストールする方法は主に3種類くらいあるようです。
- yum install --installroot でインストールする。chroot環境を作るのと似た感じ。
- ビルド済みのイメージを使う。Dockerのイメージも使えるようだ。
- すでに作成済みのコンテナからコピーする。
ひとまずオーソドックスな1.でやってみることにします。3.はあとからやります。
ZFSで作成した領域に最低限のパッケージをインストールします。
$ sudo yum -y --nogpg --releasever=7 --installroot=/var/lib/machines/es11 install systemd systemd-networkd passwd yum vim-minimal
lsで見ると、OSのイメージぽく見えます。
$ ls -l /var/lib/machines/es11/ total 17 lrwxrwxrwx. 1 root root 7 Apr 6 23:24 bin -> usr/bin dr-xr-xr-x. 2 root root 2 Apr 11 2018 boot drwxr-xr-x. 2 root root 3 Apr 6 23:24 dev drwxr-xr-x. 47 root root 113 Apr 6 23:25 etc drwxr-xr-x. 2 root root 2 Apr 11 2018 home lrwxrwxrwx. 1 root root 7 Apr 6 23:24 lib -> usr/lib lrwxrwxrwx. 1 root root 9 Apr 6 23:24 lib64 -> usr/lib64 drwxr-xr-x. 2 root root 2 Apr 11 2018 media drwxr-xr-x. 2 root root 2 Apr 11 2018 mnt drwxr-xr-x. 2 root root 2 Apr 11 2018 opt dr-xr-xr-x. 2 root root 2 Apr 11 2018 proc dr-xr-x---. 2 root root 2 Apr 11 2018 root drwxr-xr-x. 12 root root 12 Apr 6 23:25 run lrwxrwxrwx. 1 root root 8 Apr 6 23:24 sbin -> usr/sbin drwxr-xr-x. 2 root root 2 Apr 11 2018 srv dr-xr-xr-x. 2 root root 2 Apr 11 2018 sys drwxrwxrwt. 7 root root 7 Apr 6 23:25 tmp drwxr-xr-x. 13 root root 14 Apr 6 23:24 usr drwxr-xr-x. 18 root root 21 Apr 6 23:24 var
ちなみに、圧縮率を見てみると2倍以上になっていてなかなかいい感じです。lz4は圧縮率と速度のバランスが良く、ZFSを使うならおすすめです。
$ zfs get compressratio tank/machines/es11 NAME PROPERTY VALUE SOURCE tank/machines/es11 compressratio 2.03x -
コンテナを起動する
systemd-nspawn -Dオプションで、イメージをインストールしたディレクトリを指定してコンテナを起動し、rootのパスワードを設定します。
$ sudo systemd-nspawn -D /var/lib/machines/es11 -bash-4.2# passwd ... -bash-4.2# exit
SELinuxを適切に設定するか無効にしないとパスワード変更で↓のようなエラーになるようなのでご注意ください。私は恥ずかしながらSELinuxをまともに使ったことがありません。
passwd: Authentication token manipulation error
コンテナをデーモンモードで起動します。
$ sudo systemd-nspawn -b -D /var/lib/machines/es11
起動シーケンスが走って、ログインプロンプトが出てくるのでrootでログインします。
Spawning container es11 on /var/lib/machines/es11. Press ^] three times within 1s to kill container. systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN) Detected virtualization systemd-nspawn. Detected architecture x86-64. Welcome to CentOS Linux 7 (Core)! ... CentOS Linux 7 (Core) Kernel 3.10.0-957.el7.x86_64 on an x86_64 es11 login: root Password: Last login: Sat Apr 6 23:43:37 on console
ps -ef で見ると、最低限のプロセスが起動しているのがわかります。
container# ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 1 23:45 ? 00:00:00 /usr/lib/systemd/systemd root 14 1 0 23:45 ? 00:00:00 /usr/lib/systemd/systemd-journald dbus 19 1 0 23:45 ? 00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfil root 21 1 0 23:45 ? 00:00:00 /usr/lib/systemd/systemd-logind root 23 1 0 23:45 ? 00:00:00 login -- root root 25 23 0 23:45 console 00:00:00 -bash root 37 25 0 23:45 console 00:00:00 ps -ef
デフォルトでは、ホストとネットワークを共有しています。
container# networkctl status
● State: n/a
Address: 192.168.0.10 on br0
Gateway: 192.168.0.254 (JStream Technologies Inc.) on br0
Ctrl+] を3回入力するとコンテナが終了します。
Container es11 terminated by signal KILL.
ネットワークの設定を追加します。コンテナの中身はただのディレクトリなので、ホスト側からも見えます。
$ cd /var/lib/machines/es11 $ cd etc/systemd $ sudo mkdir network $ cd network
systemd-nspawnではhost0という仮想NICが自動的に作られるので、以下のように設定ファイルを作成します。
$ sudo vi host0.network ---- [Match] Name=host0 [Network] Address=192.168.0.11/24 Gateway=192.168.0.254 DNS=192.168.0.254
今度は、--network-bridge オプションを追加して起動します。
$ sudo systemd-nspawn -b -D /var/lib/machines/es11 --network-bridge=br0
host0にIPアドレスが設定されていることがわかります。これで、コンテナに独自のIPアドレスを割り当てて外部と通信できるようになりました。
container# networkctl status
● State: routable
Address: 192.168.0.11 on host0
Gateway: 192.168.0.254 on host0
DNS: 192.168.0.254
machinectl login でrootでログインできるように、/etc/securettyにpts/0を追記しておきます。
container# echo pts/0 >> /etc/securetty
いったん Ctrl+] を3回入力してコンテナを終了します。
Container es11 terminated by signal KILL.
ここからは、machinectlコマンドでコンテナを操作します。
ネットワークブリッジを使うように起動オプションを書き換えます。また、network.targetより後に起動するようにします。
$ sudo vi /usr/lib/systemd/system/systemd-nspawn\@.service > After=network.target ... < ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --network-veth --machine=%I --- > ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --network-bridge=br0 --machine=%I
machines.targetを有効にします。
$ sudo systemctl enable machines.target
machinectl enable でコンテナが自動起動するようにします。
$ sudo machinectl enable es11 Created symlink from /etc/systemd/system/machines.target.wants/systemd-nspawn@es11.service to /usr/lib/systemd/system/systemd-nspawn@.service.
machinectl start コマンドで、コンテナを起動できます。
$ sudo machinectl start es11
machinectl login コマンドで、コンテナにログインできます。
$ sudo machinectl login es11
ここまでで、コンテナを仮想サーバと同じような感覚で扱えるようになりました。
systemd-nspawn の概要は、例によって Arch Linux のページがわかりやすいと思います。
Elasticsearchをインストールする
ホスト側で、vm.max_map_countの値を増やしておきます。
$ sudo vi /etc/sysctl.d/10-vm.conf --- vm.max_map_count=262144 $ sudo sysctl -p
container# cd /etc/yum.repos.d container# vi elasticsearch.repo --- [elasticsearch-6.x] name=Elasticsearch repository for 6.x packages baseurl=https://artifacts.elastic.co/packages/6.x/yum gpgcheck=1 gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch enabled=1 autorefresh=1 type=rpm-md
Javaをインストールします。
container# yum install java-11-openjdk
Elasticsearchをインストールします。
container# yum install elasticsearch
設定を変更します。
container# cd /etc/elasticsearch
container# vi elasticsearch.yml
---
...
node.name: ${HOSTNAME}
network.host: 0.0.0.0
discovery.zen.ping.unicast.hosts: ["192.168.0.11", "192.168.0.12","192.168.0.21", "192.168.0.22"]
本番で使うなら Shard allocation awareness も考慮した方がよいと思います。
サービスを有効にします。
container# systemctl daemon-reload container# systemctl enable elasticsearch.service container# systemctl start elasticsearch.service
動作確認してみます。ひとまず単一ノードで無事に起動しているようです。
container# curl http://localhost:9200/
{
"name" : "es11",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "Rnvu_GRyQoapvhnodWHb4A",
"version" : {
"number" : "6.7.1",
"build_flavor" : "default",
"build_type" : "rpm",
"build_hash" : "2f32220",
"build_date" : "2019-04-02T15:59:27.961366Z",
"build_snapshot" : false,
"lucene_version" : "7.7.0",
"minimum_wire_compatibility_version" : "5.6.0",
"minimum_index_compatibility_version" : "5.0.0"
},
"tagline" : "You Know, for Search"
}
コンテナをコピーする
いったんコンテナを停止します。
$ sudo machinectl poweroff es11
machinectlコマンドには、export-tarというオプションがあるようなのですが、CentOS 7 に付属のものはバージョンが古いのかそのオプションがありません。
machinectl(1) — Arch manual pages
仕方がないので、rsyncでコピーすることにします。
$ cd /var/lib/machines/ $ sudo rsync -av es11/ es12 ...
Node IDが重複しないように消しておきます。
container# rm -rf /var/lib/elasticsearch/nodes/0/
ネットワークの設定を書き換えます。
$ cd es12 $ cd etc/systemd/network $ sudo vi host0.network ---- [Match] Name=host0 [Network] Address=192.168.0.12/24 Gateway=192.168.0.254 DNS=192.168.0.254
machinectl enable でコンテナが自動起動するようにします。
$ sudo machinectl enable es12 Created symlink from /etc/systemd/system/machines.target.wants/systemd-nspawn@es12.service to /usr/lib/systemd/system/systemd-nspawn@.service.
machinectl start コマンドで、コンテナを起動します。
$ sudo machinectl start es11 $ sudo machinectl start es12
2台でクラスタ構成を組めていることを確認できました。
$ curl http://192.168.0.11:9200/_cat/health?v epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent 1554574589 18:16:29 elasticsearch green 2 2 0 0 0 0 0 0 - 100.0%
ホストの追加
もう一式ホストを追加します。私はVirtualBoxのクローン機能を使って作りました。以下のあたりに気をつければ良いと思います。
- ホスト
- コンテナ
クラスタの状態を確認すると、無事に4台でクラスタ構成を組めていることを確認できました。
$ curl http://192.168.0.11:9200/_cat/health?v epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent 1554575745 18:35:45 elasticsearch green 4 4 0 0 0 0 0 0 - 100.0%
まとめ
Linuxコンテナ（systemd-nspawn）でホストまたぎのElasticsearchクラスタを構築してみました。 Docker+Kubernetes よりはるかにシンプルにできたと思います。 今回は私の趣味で ZFS on Linux を使っていますが、ほぼOS標準の機能だけでもできるので、運用の観点でも安心感があるのではないでしょうか。
今回の検証で、Linuxコンテナを完全に理解しました（※チュートリアルを終えたレベルという意味）。なお、Solarisコンテナについては何もわかりません（※10年以上キャリアグレードの商用環境で使いまくったという意味）。
Qiitaにも上げてみました。 qiita.com
ぷららのIPoEでIPv4 over IPv6を使いつつPPPoEも共存させるメモ
概要
近頃、夜間や休日などの混雑時間帯にあまりにインターネット接続の速度が遅いのでIPoE方式にしてみようと思いました。 これは、一般的な家庭である我が家でIPoE（IPv4 over IPv6）を導入したときのメモです。
元々の環境
元々のインターネット接続環境は以下のような感じです。
ぷららではIPoEサービスを「ぷららv6エクスプレス」という名前で提供しています。 2018/3/1以降にぷららに申し込んだユーザは自動的に有効になるようですが、それ以前からのユーザはマイページから自分で申し込む必要があります。 私はマイページで申し込んでから2日ほどで開通のお知らせメールが来ていました。 「ぷららv6エクスプレス」については、↓のページに説明があります。 www.plala.or.jp
機器の購入
IPoEでIPv6インターネットに接続するには、Web Caster V120でも問題ありません。IPoEが開通すると、特に何もしなくてもIPv6でつながるようになります。 しかし、IPoEでIPv4インターネットに接続するには、「IPv4 over IPv6」が必要になります。IPv4 over IPv6の方式にはDS-Lite方式やMAP-E方式などいくつかの方式があります。ぷららは方式を非公開にしていますが、MAP-E方式のサービスの1つである「OCNバーチャルコネクト」を使用しているようです。 OCNバーチャルコネクトを使用するには専用機器が必要で、今のところ「ドコモ光ルーター01」しか対応していないようです。
「ドコモ光ルーター01」はNECのAterm WG1200HPのOEM製品のようですが、ファームウェアは別物のようで、各社のIPv4 over IPv6方式に対応しているようです。無線LANルータとしてはやや割高な気はしますが、これしかないので仕方がありません。
構成の問題
さて、家庭内からインターネットに向けて接続するだけなら、Web Caster V120をドコモ光ルーター01に入れ替えてしまえばよいのですが、そう簡単にはいきません。問題点は以下の2つです。
自宅サーバはダイナミックDNSで外にIPアドレスを公開しているのですが、IPoEだとIPv4アドレスの使用には制限があります。OCNバーチャルコネクトだと、公開できるポートが限られているようでした。少なくともWebやメールで使うようなWell-Knownポートは使えません。そのため、外部に公開するIPアドレスを使用するには、PPPoE接続を残さなければいけません。 また、Web Caster V120はVoIPゲートウェイの機能を内蔵しており、我が家では電話機をつなげています。これがないと、ぷららフォン for フレッツを使用できません。あまり使うことはないのですが、それでもたまに使うのでなくすわけにもいきません。
構成案
というわけで、Web Caster V120は残しつつ、ドコモ光ルーター01を追加して、PPPoE接続かIPoE接続かを選択できるようにする方式が最もよさそうです。図にすると↓のような感じです。
VDSLモデムのLANポートは1つしかないので、WAN側にL2スイッチを挟んでWeb Caster V120とドコモ光ルーター01を接続することにしました。LAN側は、2つの機器を同一のネットワークに置いて、配下の機器ごとにデフォルトゲートウェイを選択することで接続方式を分けられるようにしました。
具体的な設定
Web Caster V120では、IPv6ブリッジ機能を無効にしておきます。これで、IPv6での通信はドコモ光ルーター01側からになります。
ドコモ光ルーター01は起動時に接続方式を自動判定します。IPoE接続は、手動では設定できないようでした。
自動判定で何をやっているのかはわかりませんが、おそらく取得したIPv6アドレスのレンジからIPoE接続事業者（VNE）を判定しているのではないかと思います。ぷららの場合は「OCNバーチャルコネクト」と判定されました。再起動を促されるので再起動します。
再起動すると、動作状態が「OCNバーチャルコネクト」になりました。これで、IPv4 over IPv6が使えるようになっています。
IPoEの動作確認は↓のサイトを使うと便利です。 ipv6-test.com
まずは、デフォルトゲートウェイをWeb Caster V120側（PPPoE接続）にした場合は以下のようになりました。IPv4アドレスがぷららのものになっているのがわかります。
続いて、デフォルトゲートウェイをドコモ光ルーター01側（IPoE接続）にした場合は以下のようになりました。IPv4アドレスがOCNのものになっているのがわかります。
Googleの「インターネット速度テスト」で速度を測ってみました。結果は一目瞭然で、IPoEが圧倒的に速いです。計測したのは土曜日の23時台なので混雑している時間帯だと思います。今はまだ設備が空いているからだとも言えますが、VDSLの限界の100Mbpsに迫る速度が出ていて驚きました。
というわけで、IPoE接続でIPv4 over IPv6を使いつつ、PPPoE接続も共存させることができました。 しかし、IPoEを巡る状況はずいぶん複雑になってるのですね。一般的なネットワークエンジニアならわかると思いますが、一般的な人にこれを理解してもらうのはかなり難しいように思います。
CISSP受験体験記
概要
CISSPの試験に合格しました。勉強期間は約4週間で、幸い一発合格できました。
CISSPは米国発のセキュリティの認定資格で、国際的に認められています。セキュリティ業界では有名な資格ですが、日本ではCiscoやOracleの資格と比べるとあまり知名度はないかもしれません。
試験の内容は、NDAにより一切口外してはいけないことになっているので、勉強方法や受験の流れについて振り返ってみたいと思います。
CISSPを目指す方の一助になれば幸いです。
勉強方法
まず、CISSPの試験はそれなりに難しいです。少なくとも、IPAの情報セキュリティスペシャリスト（今は情報処理安全確保支援士というださい名前の試験に変更）と同等かそれ以上の難易度という感想です。
難しいと思った理由は主に3つです。
(1) 範囲がすごく広い
CISSPの試験範囲は8つのドメインに分かれていますが、その1つ1つで本が何冊も書けるんじゃないかというほど広いです。 問題集には、裁判の進め方からNmapコマンドのオプションまで出てきます。全てに精通しているような人は超人だと思います。 私は、IPAのネットワークスペシャリストと情報セキュリティスペシャリストを取得していますが、それでもカバーできるドメインはせいぜい3つか4つくらいだと思います。
(2) 問われる内容がそれなりに深い
出題形式はだいたい4択問題なので、IPAの情報処理技術者試験の午前問題と似たような感じですが、同等と思うのは甘いです。午後問題程度のそれなりに深い内容を問われると思った方がよいと思います。 出てくる用語もそれなりに難解です。例えば、Certification と Accreditation の違いとか。日本語だと認証と公認という感じで違いがよくわかりませんが、両者は違います。 試験は日本語で受けられますが、外資系ベンダの試験にありがちな感じで、日本語だと意味がわからなかったり、誤訳としか思えないところもあるとかないとか。英語の原文も同じ画面で確認することができるので、英語の原文を必ず確認した方がよいと思いました。
(3) 独特で曖昧な問題が多い
この3つ目が最大の難関だと思います。問題に対する答えを覚えるだけでは全く歯が立たないと思います。 表現するのは難しいですが、自分の主観は捨てて、「CISSPであればそう考えるべきである」というような視点が必要だと思います。 CISSPは、現実的でビジネス（経営者）寄りな視点を求められるので、例えば、リスクマネジメントの目標が問われるような場合は、「リスクを完全に無くす」のではなく「（経営者が）リスクを許容できるレベルにする」のような選択肢がおそらく正解に近いんじゃないかと思います。 これは、問題集をやってみるとわかると思いますが、何を言っているのかさっぱりわからない問題が出てくると思います。私もそうでしたが、「CISSPにあるべき視点」のようなものを意識して、慣れてくるとなんとなく正解が見えてくるようになってきたと思います。
CISSPの一般的な勉強方法として、NRIさんがやってる1週間のセミナーがあります。しかし、私は未受講です。 セミナーの評判は良いのですが、受講に50万円くらいかかるのが大きな障壁です。これを受講するのは会社のサポートがないと厳しいでしょうね。 独学だと知識の偏りが気になるので、合格後でもなんとかして受講したいところです。
https://www.nri-secure.co.jp/service/isc2/cissp.html
以下に、私が勉強に用いた教材を紹介していきたいと思います。
- 作者:Susan Hansche,John Berti,Chris Hare
- 発売日: 2005/09/23
- メディア: 大型本
数少ない日本語の本です。なんとなく購入していましたが、あまりの厚さに3分の1ほど読んで挫折しました。現在は絶版になっていて、新版が予定されているようですが、紙の本はいらないかなと思います。（売却してしまいました...）
- 発売日: 2018/09/20
- メディア: Kindle版
こちらが新版です。だいぶ値上がりしましたね。。
CISSP Official (ISC)2 Practice Tests (English Edition)
- 作者:Chapple, Mike,Seidl, David
- 発売日: 2018/05/22
- メディア: Kindle版
練習問題が1300問収録された本です。私はKindle版を購入しました。比較的お手頃な価格で非常におすすめです。 この本を購入すると、本と同じ内容のテストがWebで利用できるようになります。Webテストの作りがいいので本を読むことはほとんどなかったです。
ちなみに、Webテストの登録方法は、本のあるページに書いてある内容を入力するというものでした。セキュリティ的には弱いですね :-p
Webテストはこちら https://testbanks.wiley.com/
私はまず、このWebテストで50問ほどのミニテストを作ってなんとなく実力を判定してみました。初見でおおむね7割前後は得点できていたので、苦手なドメインを中心に後述の本を拾い読みして偏りを埋めるという勉強のやり方で進めました。 ネットワークセキュリティや暗号のところは初見で8割くらい得点できましたが、米国の法律や裁判のところはさっぱりわからず、半分くらいしか得点できませんでした。 IPAの情報処理技術者試験でも法規の出題はありますが、午前問題でせいぜい数問とかなので、まるごと捨ててもなんとかなりますが、CISSPでは2,3割がそんな感じなので捨てるわけにはいかず苦労しました。考えてもわからない暗記物はかなり苦痛ですが、そういう試験なので仕方ありません。 暗記するしかない問題もありますが、大部分は考えないといけません。問題に対する答えを覚えるのではなく、なぜその答えになるのか、納得できるまで後述の本で該当箇所を勉強するのがよいと思います。
この本も非常におすすめです。これもKindle版を購入しました。こちらも登録するとWebテスト1421問を利用できるようになります。Webアプリの作りは前述の Practice Test のほうがしっかりしてます。
Webテストはこちら http://sybextestbanks.wiley.com/course/index/id/102
1000ページ以上ある辞書のような本なので、全部読むのは苦しいと思います。気になるところを拾い読みするだけでも充分勉強になると思いました。時間と根性がある人は全部読むととても勉強になると思います。 これももうすぐ新版が出るようです。
これも数少ない日本語の本です。半額になってたのでKindle版を購入してみました。 ちょっと内容が古く、ときどき誤訳じゃないかと思うところがあったりしますが、日本語で概要を捉えるにはよいんじゃないかと思います。章末の問題集が、公式の本よりひねられた感じになっていて、本番の雰囲気に近いような気がしました。
前述の Official Study Guide から、Exam Essencials と Review Questions を抜き出したようなアプリです。本があればいらない気はしますが、手軽にテストの練習ができて楽しいので、1200円がそれほど高いと思わなければ買ってもいいと思います。
申し込み～試験
福岡センタでの残念な出来事
2週間くらい勉強して、なんとなく模擬テストで8割くらい得点できていたので、そろそろ行けるかなと思って申し込むことにしました。受験するだけで7万円くらいかかる試験なので相当の覚悟が必要です。 現在のところ、日本では東京・大阪・福岡の3カ所でしか受験することができません。私が申し込もうとしたときには、東京・大阪は1ヶ月以上先までほとんど空いていませんでした。福岡だけはわりと空いていたので、たまには福岡まで旅行するのもいいかなと思って、福岡センタで受験することにしました。試験日は約2週間後にしました。
Pearson (ISC)² 認定試験 (ISC)2 :: ピアソンVUE
福岡センタは博多駅の近くにあるので、博多駅の近くで前泊しました。試験開始の30分ほど前に行き、静脈の登録や写真撮影などを行ないました。 CISSPの試験では、途中の休憩は自由で、試験ルームの外に出ることもできます。ただし、休憩中も時間は経過していきます。試験センタに来る前に、飲み物と軽食を買っておくのがよいと思います。
適当に休憩をはさみつつ、250問中150問ほど回答したところで、画面がフリーズしました。システム担当の方が慌てた感じで試験ルームに入ってきて、トラブルシューティングを始めました。どうやら、サーバのトラブルで、部屋にいた全員が影響を受けたようです。部屋には6人くらいいたと思いますが、4人くらいは試験を途中から再開できたようでした。しかし私ともう1人は、途中経過を復元できなくなってしまい、その日はもう再開できないと謝られてしまいました。 ピアソンで何回か別の試験を受けたことはありますが、こんなことは初めてです。思わぬトラブルで試験を中断されて困惑しましたが、こういうトラブルの時のシステム担当の方の気持ちは痛いほどよくわかるので、同情してしまいます。
別の日程での再試験を提案されましたが、私はわざわざ福岡まで来てるのでそれなりに旅費がかかっています。完全に先方の過失なので旅費を補填できないのか交渉しましたが、受験の規定に何が起きても受験料以上は保証できないとの記載があり、聞いてもらえませんでした。 再試験については、たまたま2日後に東京センタの空きができたようなので、東京センタで受験することとなりました。 旅費については無念な気持ちでいっぱいですが気持ちを切り替えるしかありません。わざわざ福岡まで来たのはいったい。博多でラーメンを食べて帰るだけの旅になってしまいました。
東京センタで再試験
東京センタは有楽町と新橋の中間くらいにある、帝国ホテルタワーの18階です。試験は9時からなので、30分くらい前に来て、同じように静脈の登録や写真撮影などを行ないました。
100問毎くらいに休憩を挟みつつ、2時間くらいで250問に回答しました。わからない問題にはマークを付けました。 250問一通り終わった後、50問くらいマークした問題を見直し、さらに250問全てを2回見直しました。 結局マークした50問くらいはよくわかりませんでしたが、合格基準はおおむね70%と言われていて、仮に全部外していても80%くらいは得点できているだろうと判断したので終了しました。 その時点で、3時間10分ほど経過していました。制限時間は6時間なので、時間的にはだいぶ余裕がありました。 朝の9時前から始めて、12時頃には終わっていたのでそれほどお腹も減らず、体力的にも余裕がありました。
試験終了後、結果はすぐにわかります。画面には何も出ませんが、受付で試験結果が紙で出力されます。結果を見ると、無事に合格していました。昔から、いつか取得しようと思っていた資格だったのでうれしかったです。 CISSPの試験では合格すると点数はわかりません。不合格だと弱かったドメインがわかるらしいです。
福岡で150問ほど進んでたので、本番の試験の傾向をなんとなく知ることができ、それを踏まえて余分に1日勉強できたので、再試験の時は気持ちに余裕があったように思います。結果的には良かったんじゃないかなと思いました。 合格してしまえば福岡でのトラブルもレア体験として笑い飛ばせるというものです。
今後の対応
今後は、(ISC)²に登録して正式にCISSPと認定される予定です。CISSPホルダーからの推薦（エンドースメント）が必要なので、知人のCISSPホルダーにお願いしようと思います。 知人にCISSPホルダーがいない場合は(ISC)²が直接認定してくれるようですが、レジュメを提出したりしないといけないようでちょっと面倒かもしれません。
CISSPの試験は、2018/4から大幅に変わるようなので、この記事の内容は古くなる可能性があります。最新の情報は(ISC)²のウェブサイトをご参照ください。
最も大きな変更は、試験の方式がCAT(Computer Adaptive Testing)という方式になるところだと思います。問題数が250問から100問になり、時間も6時間から3時間に短縮されるようです。難易度はおそらく上がるのではないかと思います。 現行の250問の試験では、各ドメインの出題比率が決まっているので、苦手なドメインを得意なドメインである程度カバーできますが、CAT方式だと、おそらく最初に採点に関係ない苦手なドメインを見極めるための問題が出題されて、その後苦手なドメインの問題が重点的に出題されるような形式になるのではないかと思います。 これから受験される方は、苦手なドメインがなくなるよう、より満遍なく学習するようにがんばってください。
kendama.asia
kendamaドメインを1つくらい取っておいてもいいかなと思ったので、kendama.asia ドメインを取得しました。
とりあえず Kendama Revolutions の転送アドレスとして設定しました。
http://kendama.asia/
kendamaドメインの登録状況をざっと検索してみました。
続きを読む