問われるのは技術力。だから学び続けることが重要
「Kubernetesについて紹介しようとすると1時間では話しきれない。そこで今日は当初のアジェンダを変更して、インターネットにまだあまり出てこない内容を紹介したい」
こう冒頭で切り出し、寺田氏のセッションは始まった。
2000年～2014年の14年間の間に、Fortune 500の企業のうち半数以上が倒産しているという。その背景にあるのがデジタル革命だ。現在、時価総額のトップにいるのは、AppleやAmazon、Facebook、Microsoftといった新興のデジタルネイティブな企業である。「また世界中には、今までITに直接関連しなかった企業もたくさんあるが、こうした伝統的な企業は、デジタルネィティブな新興企業が発明するサービスから危険に晒されている」と寺田氏は話す。例えば米タクシー会社であるイエローキャブ社はUberやLyftに乗っ取られつつある。
グローバルマーケットにおける日本企業の地位も低下している。寺田氏は平成元年と平成30年の世界時価総額ランキングを提示。平成元年のランキングでは、トップ50位以内の多くが日本企業で占められていた。しかし現在、50位以内にランキングされているのはトヨタ自動車の1社のみ。しかも時価総額は30年間で541億円から1939億円と、約4倍の成長しかない。「もうひとつ注目してほしいのが、50位のNetflix。テレビ会社が入っていないのに、新興のNetflixが入っている。これが現実だ」と寺田氏は続ける。
ではこうした厳しい現実の中で、どうすれば企業は生き残ることができるのか。既存のエンタープライズ企業は、DevOpsやOSS活用による、いち早いサービスの提供、不確実性が当たり前としたトライアンドエラー、顧客ごとに予想していくためのビッグデータの活用など、デジタルネイティブな新興企業のやり方を模倣し出している。つまり「重要なのは会社が変わること」だという。
一方、エンジニアとして生き残るためには何が必要か。「それは腕、つまり技術力だ」と寺田氏は続ける。
「どこの会社で働いていたかは関係ない。そこで何をやったのか、どういう技術力を持っているのか。それがちゃんと話せるエンジニアが価値のあるエンジニアとして生き残っていける。そのためには学び続ける姿勢が重要だ。これをやめるとエンジニアではなくなってしまう。もうひとつ大切なのは英語力。もし今新しいプログラミング言語を覚えようと考えているのなら、それではなく、ぜひ英語を勉強してほしい。新しい技術をキャッチアップする時間は英語力によって大きく変わるからだ」
アプリケーション開発のトレンドも年々変わっていく。それをどう選択していけばいいのか。「銀の弾丸はない。したがって最も重要なのは、『このシステムにはKubernetesが合う』『このシステムはKubernetesではない』といった技術の見極め、適材適所に選択する力を身につけることだ」と寺田氏は語る。そしてもうひとつ覚えておきたいのが、他社の成功事例をマネても意味がないということ。
「ノウハウとして参考にするのであればいいが、他の企業でうまくいったやり方をそのまま自社でやってもうまくいかない。自社にとって最適な構成を一生懸命考えることだ」
モノリシックとマイクロサービスのどちらがいいのか、「これも銀の弾丸はない」と寺田氏は言う。考えなければならないのは、何のためのマイクロサービスなのかということ。「いち早くサービスを提供したい」「柔軟にスケールしたい」「独立したサービスを行いたい」「耐障害性を高めたい」「変更に強いシステムを作りたい」など、目的はさまざまだろう。
最もダメなパターンは、Dockerを導入したいからといってマイクロサービスに手を出すことだ。例えば先に挙げた、「いち早いサービスの提供」「柔軟なスケール」「独立したサービス作り」は、マイクロサービスではなくIaaSやPaaSでも実現できる。マイクロサービスが有効なのは、「変更に強いシステム」といった動きのあるシステムを作る場合だという。
では変更に強いアプリケーション開発をどうやって実現していくのか。まずはTwelve-Factor AppやThe Reactive Manifesto、組織作り、TDD（テスト駆動開発）、アジャイル、継続的インテグレーション、Infrastructure as Code、継続的デリバリーなど、マイクロサービス化するために必要な知識を獲得することだ。というのも、マイクロサービスはモノリシックのアプリケーションの作り方とはまったく異なるからである。
次にソースコード管理の方法から変えること。寺田氏は「マイクロサービスではサービスごとにレポジトリを作成するべき」と指摘。なぜなら、サービスごとの履歴管理・ロールバックの把握が容易になるからだ。
3つ目は並列処理や非同期、ノンブロッキングの処理をきちんと考えること。例えばすべてのサービスの呼び出しを同期型で書くと、いち早く開発できるかもしれない。しかしすべての処理が終わるのに時間がかかる。これを並列処理にすることで、処理にかかるトータル時間を短くできる。パフォーマンスやリソースの使用量に大きく影響するため、これらの仕組みを理解することが今後は非常に重要となる。
4つ目は障害が起きることを常に頭に置いておくこと。「今まで冗長構成や二重化を行ってサービスが落ちないように頑張ってきた。しかし、サービスは落ちるしネットワークも止まる。だからこそ、これからは1つサービスが落ちても他に影響しないような作り方をすることが重要になる」と寺田氏は言う。つまり重要になるのは分散コンピューティングを意識したシステム開発である。それを学ぶためにおすすめの書籍が『Release It! 本番用ソフトウェア製品の設計とデプロイのために』。
「古い書籍だが、この本にマイクロサービスをやる上で重要なことが書かれているので、ぜひ読んでほしい」
Kubernetesでつまずきやすいポイントとその解消策
Azureにおいてもコンテナを動かす仕組みが用意されている。それが「Web App for Containers」「Container Instances」「Azure Kubernetes Service（AKS）」である。
Web App for ContainersはLinux上で、コンテナを単体で動かしたり、Docker Swarmの構成を使って複数のコンテナを動かしたりできるサービスだ。
Container Instancesは、コマンド1つでAzure上のコンテナを実行して起動できるサービス。「サービスを動かしているときだけ課金されるので、コストを抑えられる。バッチといった短命な処理のサービスに向いている」と寺田氏は説明する。
Azure Kubernetes Serviceは、ホストされているKubernetes環境を容易に管理できるサービスである。「DevOpsやマイクロサービスを意識したアプリケーションを作る際は、ぜひ検討してほしい」と寺田氏。またAzureでは、Kubernetes以外にも「OpenShift」や「Pivotal Cloud Foundry」も利用可能だ。
Kubernetesは容易に扱える技術ではない。「よくQiitaなどで、『たったこれだけの設定でコンテナ2つを動かせます』といった定型ファイルを見かけるが、これは単に動いたというだけ。本番環境で適用できるとは思わないでほしい」と寺田氏は注意を促す。本番環境で適用するなら、リソースやディスク、ネットワーク、無停止更新、可用性、セキュリティ、パフォーマンスなど、検討すべき要素がたくさんあるからだ。例えば無停止更新をするには、下図の通りに書かなければならない。
しかもKubernetesは数カ月に1回はバージョンアップされるなど、進化が激しい。「ひとつバージョンが変わると、今まで書いていたYAMLが動かなくなることは当たり前。進化が早いのでサードパーティー系のツールもどんどん登場しており、絶対、ハマってしまう」と寺田氏。ここで言うハマるとは、つまずくことだ。寺田氏がハマったポイントは6つあるという。
うち1つはKubernetesのバージョンアップで壊れたということ。「これはAzureに限った話ではない。ローリングアップデートはやってくれるが、失敗する可能性がある。バージョンアップをしなければならない場合は、最新のクラスタを1つ作り、今まで動いていたものをそのままコピーする。そしてカナリアリリースのように最初は8割のリクエストを古い方に飛ばし、2割を新しい方に飛ばす。それがうまくいってから、徐々に移行させることをおすすめする」と寺田氏は話す。
その他にもVMのスケールで失敗したり、podを作成し過ぎてコマンド操作が不可能になったり、バージョンアップで既存の設定が動かなかったり、PV（Persistent Volumes）のアタッチ・デタッチができない、もしくは時間がかかったり、Istio Heotio Arkといった周辺ツールの導入・設定が容易にできなかったりした。
「ハマったときに実施したいのは、次の5つ」と寺田氏は解説する。
- kubectl describe pod
- kubectl logs POD_NAME
- kubectl exec -it POD_NAME /bin/sh
- kubectl get events -w
- Ubuntuを同一名前空間にデプロイ
これでもダメならStack OverflowやGitHubのIssueを見にいく。「私はこの手順で解消している。Kubernetesを触るときにはハマる覚悟を持って立ち向かってほしい」と寺田氏。
Kubernetesを扱う上で大事なのは、開発者と運用者双方にノウハウが必要なこと。なぜならKubernetesはDevのツールでもOpsのツールでもなく、DevOpsのツールだからだ。そのためにも、とにかく「経験と知識を積み重ねていくしかない」と言い切る。
ちなみにKubernetesの技術的な情報については、寺田氏もGitHubで公開しているという。「k8s-Azure-Container-Service-AKS--on-Azure」のリンクをクリックすると、Kubernetesに関するさまざまな情報が得られる。
Javaの開発・提供もアジャイル的に進んでいる。今月リリースされたJDK11では、コンテナ対応がさらに進んだ。しかもこれからは半年に1回バージョンアップされていく。「ぜひ、最新のJavaを試してほしいが、Kubernetes同様、おそらく最初はハマる」と寺田氏。なぜなら、JDK11よりJava SEからjava.xml.ws（JAX-WS、Webサービス）、java.xml.bind（JAXB）、jdk.xml.ws（JAX-WS用ツール）、jdk.xml.bind（JAXB用ツール）などのパッケージが削除されたからだ。「JAX-WSやJAX-BはMavenのパブリックレポジトリの方に上がっているので、POMファイルや定義ファイルの中に書けば動かすことができる」と寺田氏。
また、カスタムのスモールJDKを作ることができるようになった。
「アプリケーションを動かすために最低限必要なJRE（Java Runtime Environment）を自分自身で『jlink』というコマンドを使って作れるようになった。特にコンテナ系でJavaを運用する際には、こういったカスタムのJREを作ることは必須になってくるので、ぜひ覚えてほしい」
マイクロソフトではJava開発者向けに、Azure上でサービスを提供する際に参考となるドキュメントを日本語で提供している。
最後に寺田氏は次のように語り、セッションを締めた。
「将来は今日から始まる。新しいテクノロジーをキャッチアップし、良いものを作っていけば、エンジニアの私たちが世界を変えていける。ぜひ、一緒に良い社会を作っていきましょう」
お問い合わせ
日本マイクロソフト株式会社
